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Executive  Summary 


The  overall  objective  of  the  Department  of  Defense  Computer-aided 
Acquisition  and  Logistic  Support  (CALS)  Program  is  to  integrate 
the  design,  manufacturing,  and  logistic  functions  through  the 
efficient  application  of  computer  technology.  CALS  is  a  program 
to  apply  existing  and  emerging  communications  and  computer-aided 
technologies  in  DoD  and  industry  to: 

o  Integrate  and  improve  design,  manufacturing,  and  logistic 
functions;  thereby  bridging  existing  "islands  of 
automation. " 

o  Actively  influence  the  design  process  to  produce  weapon 
systems  that  are  more  reliable  and  easier  to  support  and 
maintain. 

o  Shift  from  current  paper-intensive  weapon  support 
processes  to  a  highly  automated  mode  of  operation,  based 
on  a  unified  DoD  interface  with  industry  for  exchange  of 
logistic  technical  information  in  digital  form. 

The  CALS  program  was  established  by  the  Deputy  Secretary  of  Defense 
in  September  1985  to  implement  the  recommendations  of  a  Joint 
Indus try/DoD  Task  Force.  Management  is  provided  by  a  DoD  Steering 
Group,  the  OSD  CALS  Office,  and  a  lead  organization  in  each 
Military  Department  and  the  Defense  Logistics  Agency.  The  DoD  CALS 
Office  has  obtained  the  support  of  the  National  Institute  of 
Standards  and  Technology  in  the  selection  and  implementation  of 
CALS  standards.  An  Industry  Steering  Group  has  also  been 
established  to  focus  the  work  of  key  industrial  associations  and 
the  defense  contractor  community  in  CALS  implementation. 

The  CALS  strategy  provides  a  plan  for  phased  implementation  of 
CALS.  Phase  I  will  apply  current  computer  technology  in 
axisting/emerging  DoD  and  industry  systems  for  key  logistic  and 
design  applications.  Phase  II  will  involve  broad-based  DoD  and 
industry  system  redesign  to  implement  advanced  technology  across 
a  wider  range  of  applications  during  the  early  1990 's.  DoD  is 
currently  developing  core  Phase  I  requirements.  Demonstrations 
and  prototypes  will  support  Phase  I  implementation,  while  advanced 
technology  R&D  continues  for  Phase  II. 


Implementation  of  the  CALS  program  will  result  in: 

o  Design  of  more  supportable  weapon  systems, 

o  Increased  productivity  and  reduced  cost  of  weapon  system 

acquisition  and  logistic  support, 
o  Improved  timeliness  and  accuracy  of  logistic  technical 
information. 

o  Enhanced  operational  readiness  of  military  forces. 

During  FY86  NIST  recommended  standards  to  OSD  which  would  be 
applicable  to  the  DoD  environment.’  These  recommendations  included 
CALS  use  of  standards  in  the  areas  of  product  definition, 
graphics,  text,  and  data  management. 

CALS  support  work  in  FY87  focussed  on  the  following  activities: 
Developing  a  CALS  framework.  Development  Plan  and  Core  Requirements 
package;  providing  technical  support  for  standards  development  and 
implementation;  and  conducting  workshops  and  meetings  to  promote 
dialogue  with  the  Services,  the  Defense  Logistic  Agency,  and 
industry.  A  major  thrust  was  the  completion  of  the  initial 
documentation  of  the  high-priority  standards  required  for  CALS 
implementation.^ 

During  FY88,  a  number  of  efforts  advanced  the  development  of 
technology  and  standards  in  support  of  CALS.  These  efforts  were 
organized  into  the  areas  of  Text,  Graphics,  and  Product  Data. 

Text;  Work  on  text  and  graphics  standards  in  the  CALS  publishing 
environment  included  technology  assessments,  development  of 
application  guidance,  conformance  test  plans  and  a  draft  FIPS  for 
ODA/ODIF.  Additionally,  a  technology  assessment  and  proposed 
conformance  testing  strategy  were  developed  for  page  description 
languages. 

Graphics:  The  CALS  efforts  in  CGM  were  continued  and  included  work 
in  the  graphics  standards  committees  and  the  expansion  and  updating 
of  the  CALS  CGM  Application  Profile.  The  Application  Profile  was 
developed  into  a  draft  military  specification.  The  draft  was 
carried  through  the  needed  review  and  comment  process  and  was 
published  as  MIL-D-28003  in  December  1988.  In  addition,  work  on 
Extended  CGM,  or  CGEM  for  CALS  application  was  initiated.  Work  in 


’Kemmerer,  S.,  Editor,  "Final  NBS  Report  for  CALS,  FY86,"  U.S. 
Department  of  Commerce,  National  Bureau  of  Standards,  NBSIR  87- 
3566,  May  1987. 

^Kemmerer,  S.  Editor,  "A  Collection  of  Technical  Studies 
Completed  for  the  Computer-aided  Acquisition  and  Logistic  Support 
(CALS)  Program,  Fiscal  Year  1987,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-3726,  NBSIR  88-3727,  NBSIR 
88-3728,  and  NBSIR  88-3729,  March  1988. 
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the  area  of  raster  graphics  continued.  A  draft  MILSPEC  for  raster 
was  developed  which  was  later  published  as  MIL-R-28002.  The  need 
for  standards  for  the  interchange  of  large  format  tiled  raster 
documents  was  identified,  and  related  technical  papers  were 
published  separately  as  an  NIST  Internal  Report.^ 

Product  Data:  The  use  of  the  Information  Resource  Dictionary 
System,  (IRDS,  ANSI  Standard  X3. 138-1988)  was  proposed  as  an 
integration  and  configuration  management  mechanism  for  the  Product 
Data  Exchange  Specification  (PDES) . 


^Spielman,  F.  ,  Editor,  "Standards  for  the  Interchange  of  Large 
Format  Tiled  Raster  Documents,"  U.S.  Department  of  Commerce, 
National  Bureau  of  Standards,  NBSIR  88-4017,  December  1988. 
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These  three  volumes  are  a  collection  of  the  final  reports  presented 
to  the  DoD  CALS  Office/  The  collection  is  divided  as  follows: 

VOLUME  1. 

Text,  Security,  and  Data  Management 

Text  and  Graphics  Standards  in  the  CALS  Publishing  Environment 
ODA/ODIF  Application  Guidance 

Federal  Information  Processing  Standards  Publication  (Draft) 
on  Document  Application  Profile  for  the  Office  Document 
Architecture  (ODA)  and  Interchange  Format  Standard 

ODA/ODIF  Conformance  Test  Plan 

PDLs:  A  Technology  Assessment 

SPDL  Conformance  Strategy 

Security 

Risk  Management  Tools:  A  Guide  to  Selection  and  Use 

Computer  Security  Issues  in  the  Application  of  New  and 
Emerging  Information  Technologies 

Data  Management 

Information  Resource  Dictionary  System:  An  Integration 
Mechanism  for  Product  Data  Exchange  Specification 

Using  the  Information  Resource  Dictionary  System  for  PDES 

VOLUME  2: 

Graphics,  CGM  MIL-SPEC 

CGM  Conformance  Testing 
Final  Phase  I.l  CGM  MILSPEC 
Extended  CGM  MILSPEC  Planning 


^The  publishing  of  this  collection  of  reports  does  not  imply 
that  the  CALS  Office  has  endorsed  the  conclusions  or  recommenda¬ 
tions  presented. 
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VOLUME  3; 


Graphics,  CGM  Registration 

CGM  Registration  in  Support  of  CALS 


The  following  additional  publications  were  completed  by  NIST  during 
FY87  under  separate  cover.  They  are  available  through  NTIS. 


CALS  Workshop  Proceedings:  CALS  EXPO  '88  'Quality  and  Producti¬ 
vity  Through  Integration"  A  DoD/Industry  NIST 
Conference  4-6  October  1988 


MIL-HDBK-59,  Military  Handbook:  Department  of  Defense  Computer- 

aided  Acquisition  and  Logistic  Support  (CALS) 
Program  Implementation  Guide 

MIL-STD-1840A,  Automated  Interchange  of  Technical  Information 


MIL-D-28000,  Military  Specification:  Digital  Representation  for 

Communication  of  Product  Data:  IGES  Application 
Subsets 


MIL-M-28001, 


MIL-R-28002 , 

MIL-D-28003 , 


Military  Specification:  Markup  Requirements  and 
Generic  Style  Specification  for  Electronic  Printed 
Output  and  Exchange  of  Text 

Military  Specification:  Raster  Graphics 
Representation  in  Binary  Format,  Requirements  for 

Military  Specification:  Digital  Representation  for 
Communication  of  Illustration  Data:  CGM  Application 
Profile 
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CGM  CONFORMANCE  TESTING 


I .  PURPOSE 

Accelerate  development  of  CGM  (Computer  Graphics  Metafile) 
validation  routines  and  ensure  the  input  of  CALS  requirements  in 
national  and  international  standards  processes.  Prepare  a  plan 
and  recommendation  for  certification  of  a  testing  laboratory 
(CALS  SOW  Task  3.1.1). 


II.  BACKGROUND 

1.0  Conformance  Provisions  of  FIPS  PUB  128,  the  CGM  Standard 

The  conformance  statements  in  the  CGM  standard  relate  to  the 
conformance  of  a  metafile.  They  do  not  refer  to  the  conformance 
of  the  generator  or  interpreter.  There  can  be  no  expectation 
that  a  metafile  sent  to  an  unknown  interpreter  will  be  understood 
by  that  interpreter.  Groups  of  users,  such  as  CALS  and  MAP/TOP 
users,  are  concerned  about  this,  and  are  trying  to  reduce  the 
problem. 

The  CGM  standard  defines  two  levels  of  conformance:  full 
conformance  and  functional  conformance.  Full  conformance  occurs 
when  a  metafile  conforms  to  the  abstract  functional  specification 
of  Part  1  of  the  CGM  standard,  and  also  uses  one  of  the  three 
standard  encodings.  Functional  conformance  of  a  metafile  occurs 
when  a  metafile  conforms  to  the  abstract  functional 
specification,  but  a  private  encoding  is  used. 

Thus,  the  standard  is  very  limited  in  its  conformance 
requirements.  As  cautioned  in  previous  reports,  and  it  still 
holds  true — when  CGM  software  is  purchased,  there  can  be  no 
guarantee  of  minimum  support  by  generator  or  interpreter 
software . 


2.0  FY  *87  CALS  Accomplishments 

NIST/NCSL  (National  Institute  of  Standards  and 
Technology/National  Computer  Systems  Laboratory — 
formerly  NBS)  was  able  to  set  direction  for  an  architecture  for 
the  development  of  CGM  conformance  tests  to  coincide  exactly  with 
recommendations  to  CALS.  First  was  that  testing  to  the  standard 
itself  is  not  enough;  the  tests  must  include  the  CGM  generators 
and  interpreters.  Part  of  the  work  last  fiscal  year  was  to 
develop  a  plan  for  the  development  of  additional  conformance 
tests  needed  to  validate  software  that  generates  and  reads 
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metafiles,  in  the  form  of  a  reference  implementation  for  CGM. 
The  approach  taken  in  defining  these  tests  has  been  to  develop  a 
plan  for  a  reference  implementation  for  metafile  generators  and 
interpreters,  or  a  piece  of  software  capable  of  generating  any 
legal  metafile  and  capable  of  interpreting  any  legal  CGM, 
including  testing  for  the  CALS  Application  Profile  (AP) .  In 
particular,  one  of  last  year's  reports  provides  a  functional 
specification  and  conceptual  design  for  this  reference 
implementation,  as  well  as  how  it  might  be  used  as  a  basis  for 
CGM  testing  tools  or  as  a  model  for  a  CGM  test  service. 

Second,  the  international  test  centres  initially  agreed  to  test 
to  CGM  Application  Profiles,  a  concept  that  NIST/NCSL  introduced 
at  a  key  workshop  in  England.  NIST/NCSL  defined  a  CGM 
Application  Profile  for  CAEjS,  which  became  the  basis  for  MIL-D- 
28003  (formerly  MIL-D-CGM) .  These  terms  have  been  used 
interchangeably  to  mean  the  same  thing;  just  remember  that  MIL-D- 
28003  is  the  most  current  designation. 


3.0  Reasons  for  the  CGM  Application  Profile 

The  CGM  standard  offers  a  useful  method  for  the  storage  of 
graphical  images.  It  defines  a  wide  range  of  options  which  can 
be  used  by  the  generating  software.  These  options  include,  for 
example,  the  precision  of  the  data  which  is  stored  and  the  way 
that  color  is  defined  within  the  metafile.  As  stated  above  there 
is,  however,  no  guarantee  that  the  interpreting  software  will  be 
able  to  make  any  sense  of  the  metafile.  The  standard  does  not 
specify  the  behavior  of  generators  and  interpreters,  and  this 
makes  it  difficult  for  the  purchaser  of  CGM  software  to  guarantee 
that  the  software  for  generating  and  interpreting  metafiles  is 
what  is  required.  Application  profiles,  such  as  the  one  designed 
for  CALS,  attempt  to  define  the  use  of  the  standard.  Those 
parties  who  use  the  CALS  Application  Profile  should  be  able  to 
predict  the  behavior  of  the  generator  and  interpreter  software. 
The  metafiles  written  by  one  CALS  application  can  thus  be 
assured  -O  understood  when  transferred  within  the  CALS 
environment. 


4.0  Need  for  Testing  to  FIPS  PUB  128  and  to  MIL-D-28003 

It  is  important  to  ensure  that  the  CALS  Application  Profile  is 
adhered  to  by  software  purchased  for  the  CALS  effort.  Therefore, 
it  is  necessary  to  offer  some  form  of  testing  service  for 
software  to  ensure  that  software  does  conform  to  the  standard  and 
to  the  CALS  Application  Profile. 

Testing  is  important  for  ensuring  that  implementations  do  conform 
to  the  standards.  Using  existing  testing  methods  it  is 
impossible  to  guarantee  that  there  are  no  errors  in  a  product. 
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The  testing  strategy  usually  adopted  attempts  to  sh<5w  the 
presence  of  errors  in  the  product.  If  a  suitably  large  number  of 
test  cases  is  used,  then  confidence  can  be  built  in  a  product 
which  handles  these  tests. 

Existing  validation  suites  adopt  this  philosophy  and  use  a  black 
box  approach  to  testing;  that  is,  the  external  specification  or 
interface  specifications  of  the  product  are  examined  and  test 
cases  generated,  but  no  information  is  required  about  the 
internal  workings  of  the  implementation  being  tested. 

Exhaustive  testing  is  ideal  but  may  be  uneconomic  to  achieve. 
The  best  that  can  be  achieved  is  to  select  a  wide  variety  of  test 
cases  to  exercise  the  implementation  under  test  as  fully  as 
possible.  It  is  important  to  ensure  that  the  test  cases 
generated  have  a  high  probability  of  detecting  any  errors  in  the 
implementation . 


4 . 1  International  Testing  Efforts 

NIST  is  also  pursuing  a  standard  at  the  international  level  for 
conformance  testing  of  implementations  of  graphics  standards 
(Reference  9) .  This  standard  is  still  in  early  draft  stage,  but 
it  will  specify  a  methodology  for  testing  conformance  to  computer 
graphics  standards  of  products  which  claim  to  implement  these 
standards.  This  standard  will  directly  address  test 
requirements,  test  specifications,  test  suite,  test  procedures, 
and  certification  mechanisms. 


4.2  FIPS  Testing  Efforts 

In  addition,  NIST/NCSL  has  the  goal  of  providing  an  initial 
structure  and  approach  to  uniform  conformance  testing  programs 
Government-wide  for  appropriate  FIPS  Publications.  The  current 
initiative  is  the  development  and  review  of  a  draft  FIPS 
(Reference  8)  on  conformance  testing  which  will  provide  policy 
and  guidelines  for  individual  FIPS  conformance  testing  program 
development. 

The  overall  NCSL  conformance  program  and  an  individual 
conformance  testing  approach  for  any  given  standard,  will  be 
continually  developed  as  various  testing  procedures  are 
prototyped;  test  cases  are  gathered,  studied,  and  evaluated; 
industry  and  other  national  European  programs  are  studied;  and 
experience  is  gained.  This  evolution  will  also  apply  to  the 
various  conformance  testing  programs  for  graphics.  Any 
conformance  testing  program  that  NIST/NCSL  advocates  for  use  by 
DOD  CALS  will  be  based  on  this  approach  to  testing  being 
developed.  In  the  case  of  the  CGM  standard,  this  will  also  mean 
adding  conformance  testing  to  test  conformance  to  MIL-D-28003. 
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Ill .  DISCUSSION 


1 . 0  Ob j  ectives 

The  objectives  of  this  task  were  to: 

1.  Perform  a  study  of  the  variability  of  commercial  CGM 
generator  implementations,  including  the  degree  of 
conformance  to  the  CALS  Application  Profile  for  CGM. 
Note  that  this  comparison  is  made  with  the  April  1988 
version  of  this  specification.  These  commercial 
implementations  are  analyzed  in  section  3  below, 
compared  to  MIL-D-28003  in  section  4  below,  and  both 
aspects  summarized  in  sections  IV,  svibheadings  1  and  2. 

2.  Assess  the  impact  of  CGM  test  development  strategy  with 
respect  to  the  CALS  environment  and  the  marketplace. 
This  is  accomplished  in  section  V. 

3.  Provide  input  and  recommendations  for  a  plan  for  CALS 
on  how  certification  of  CGMs  to  the  Application  Profile 
could  be  handled.  This  involves  preparing  a  list  of 
tasks  that  must  be  accomplished  in  order  to  put  in 
place  a  testing  service  (both  for  FIPS  PUB  128  and  MIL- 
D-28003)  that  is  consistent  with: 

a.  The  draft  proposed  FIPS  on  Conformance  Testing 
Policy  and  Procedures  (Reference  8) ,  and 

b.  The  working  Draft  International  Standard  (DIS) , 
'•Conformance  Testing  of  Implementations  of 
Graphics  Standards  (Reference  9)  . 

These  testing  tasks  are  developed  in  section  5  below, 
and  summarized  in  section  V,  subheading  section  3. 


2 . 0  CALS  Requirements 

2 . 1  Review  of  CALS-Related  Requirements  for  Standards 

References  1  and  2  contain  analyses  of  CALS  requirements  for 
graphics-related  standards  in  the  areas  of  engineering  design, 
technical  publishing,  procurement  support,  and  interactive 
delivery  systems. 

This  report  focusses  on  the  picture  interchange  requirements  of 
CALS  when  applied  to  the  task  of  technical  manual  publishing  and 
illustration. 
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2.2  Role  of  the  CGM  in  CALS 

2.2.1  The  Computer  Graphics  Metafile 

The  CGM  provides  a  file  format  suitable  for  the  storage  and 
retrieval  of  picture  description  information.  The  file  format 
consists  of  an  ordered  set  of  elements  that  can  be  used  to 
describe  pictures  in  a  completely  device-independent  way.  One  or 
more  pictures  can  be  stored  in  a  single  metafile,  and  the 
metafile  is  defined  in  such  a  way  that,  in  addition  to  sequential 
access  to  the  whole  metafile,  random  access  to  individual 
pictures  is  well  defined.  That  is,  the  pictures  are  completely 
independent,  one  from  another:  their  appearance  does  not  depend 
upon  the  order  in  which  they  are  accessed  or  displayed. 

In  addition  to  a  functional  specification,  the  CGM  standard 
documents  three  standard  encodings  of  the  metafile  semantics. 
The  Character  encoding  requir-^s  minimum  metafile  size  and  is 
suitable  for  transmission  across  networks  of  heterogenous  systems 
but  is  expensive  to  encode  and  decode.  The  Binary  encoding 
requires  minimum  effort  to  generate  and  interpret  but  is  not 
well-suited  for  exchange  between  computers  of  different 
arithmetic  data  types.  It  is  nearly  as  efficiently  coded  as  the 
Character  encoding.  The  Clear-text  encoding  provides  maximum 
readability  and  editability  for  ease  of  use  by  humans  (e.g.,  for 
debugging  purposes)  but,  generally,  pays  a  heavy  penalty  in  size 
and.  performance.  The  size  is  much  larger  because  English  and 
other  natural  languages  contain  a  lot  of  redundancy.  The 
performance  is  worse  because  parsing  and  recognizing  text  strings 
and  converting  text  strings  to  internal  numbers  for  use  by  a 
graphics  subsystem  is  expensive  in  its  use  of  CPU  cycles. 

In  reference  1,  the  standardized  CGM  elements  are  listed  by  type. 
The  ESCAPE  and  APPLICATION  DATA  elements  have  been  provided  to 
support  uses  of  the  CGM  in  ways  that  go  beyond  the  exchange  of 
pictures.  Nongraphical  data  and  graphical  elements  not  yet 
standardized  can  be  incorporated  into  metafiles  in  a  regular  way. 
When  these  extended  metafiles  are  exchanged  by  cooperating 
processes,  standard  commercial  products  can  be  used  to  handle  the 
standard  metafile  elements,  and  new  code  need  be  written  only  for 
the  special,  non-standardized  elements.  Large  groups  of  users  of 
extended  metafiles  can  get  together  and  agree  upon  a  set  of 
extensions — just  like  MAP  and  TOP  users  have  agreed  upon 
guidelines  to  the  implementation  of  the  OSI  standards.  For 
example,  the  elements  of  a  business  chart — like  legend  entries, 
tick  marks,  and  axis  labels — or  the  elements  of  a  project 
schedule — like  PERT  chart  symbols,  milestone  markers,  or  title- 
could  be  marked  in  the  metafile.  An  editing  program  could  be 
written  to  read  such  metafiles  and  allow  modifications  to  them 
before  rendering  the  chart  on  a  hardcopy  device  or  including  it 
in  a  report  or  manual. 
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In  the  absence  of  any  facsimile  standard  capable  of  handling 
multicolor  images  (i.e.,  those  with  more  than  one  bit  per  pixel), 
a  CGM  employing  only  the  CELL  ARRAY  primitive  could  be  used. 
Images  expressed  with  either  indexed  and  direct  color 
specifications  can  be  represented.  In  the  Character-Coded  and 
Binary  encodings,  run-length  encoding  may  be  used  to  reduce  the 
size  of  the  resulting  CGM  files. 


2.2.2  The  CALS  Application  Profile  for  CGM 

Reference  5,  MIL-D-28003,  specifies  a  set  of  conditions  to  be  met 
by  CGM  generators  and  interpreters  if  they  are  to  be  said  to  be 
"conforming"  to  the  CALS  Application  Profile  for  CGM.  This 
report  is  particularly  interested  in  those  requirements  that  must 
be  met  for  an  implementation  to  be  certified  as  a  CALS 
"conforming  basic  generator"  (see  3.1.1,  Reference  5). 

The  specific  requirements  that  must  be  met  are  elaborated  in 
detail  in  section  5.3.2  below. 


3.0  Commercial  Implementations  of  the  CGM 
3 . 1  Overview 

The  objective  was  to  determine  to  what  degree  current  commercial 
implementations  of  CGM  generators  adhere  to  the  requirements  of 
MIL-D-28003  for  conforming  basic  generators. 

[NOTE:  This  report  is  intended  to  be  informative  in  terms  of 
this  comparison,  and  not  a  critical  evaluation  of  any  commercial 
software  system.  Inclusion  of  any  software  system  in  the 
following  sections  in  no  way  implies  a  recommendation  or 
endorsement  by  NIST  or  DoD,  and  the  presentation  should  not  be 
construed  as  a  certification  that  any  system  does  or  does  not 
provide  the  indicated  capabilities.  Further,  if  any  software 
system  has  been  omitted  from  this  study,  that  does  not  imply  that 
its  capabilities  are  more  or  less  than  those  of  systems  included 
herein. ] 

Most  implementations  of  generators  were  developed  with  little  or 
no  knowledge  of  the  CALS  requirements  for  CGMs.  Consequently, 
these  implementations  reflect  the  company's  judgments  as  what 
features  are  needed  in  their  commercial  marketplace  without 
regard  for  special  requirements  from  DoD. 

Over  100  metafiles  from  24  products  offered  by  20  companies  and 
organizations  were  examined.  Many  of  the  products  share 
underlying  CGM  generation  technology.  Five  of  the  products  use 
some  release  of  Graphics  Software  Systems'  GSS*CGM;  four  are 
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based  on  the  generator  libraries  licensed  from  Henderson 
Software;  three  on  the  GKS  Metafile  Output  workstation  of: 
Advanced  Technology  Center's  (ATC's)  GRAFPAK-GKS;  and  two  on  Nova 
Graphic  International's  GKS  CGM  generation  capability. 

All  CGMs  analyzed  followed  the  Binary  Encoding. 

Those  CGMs  based  on  technology  from  Henderson  Software,  ATC,  and 
McDonnell  Douglas  are  more  likely  to  pay  some  attention  to  the 
specifications  in  the  TOP  Application  Profile  for  CGM,  precursor 
and  model  for  the  CALS  Application  Profile. 

All  of  the  metafiles  were  generated  on  either  PCs  or 
workstations.  None  of  them  were  generated  on  Apple  Macintoshes. 

In  section  3.2  below,  an  overview  of  the  CGMs  written  by  each  of 
the  various  products  is  provided  without  explicit  reference  to 
the  requirements  of  MIL-D-28003.  Then,  in  section  4  below,  to 
what  degree  the  CGMs  produced  by  each  of  these  products  conforms 
to  the  requirements  of  MIL-D-28003  is  specifically  evaluated. 


3 . 2  Product  Analyses 

3.2.1  Advanced  Technology  Center 

ATC  has  developed  its  own  base  technology  as  a  GKS  metafile 
output  workstation  driver,  accessed  through  its  GRAFPAK-GKS.  The 
driver  can  generate  multiple  pictures  per  metafile. 

The  Metafile  Descriptor  sets  16-bit  integer  VDCs;  16-bit  integer, 
index  precision;  and  (16,16)  fixed-point  real  precision.  Colour 
and  colour  index  precision  is  always  8-bits,  and  colour  value 
extent  is  always  255. 

There  is  no  use  of  Metafile  Defaults  Replacement,  Font  List, 
Character  Set  List,  and  Character  Coding  Announcer. 

There  is  no  use  of  Scaling  Mode,  Colour  Selection  Mode,  or  any  of 
the  Specification  Modes.  Background  Colour  is  used. 

The  generator  does  not  use  Auxiliary  Colour,  Transparency,  and 
Clip  Indicator.  It  does  use  Clip  Rectangle. 

The  generator  does  not  use  Disjoint  Polyline,  Restricted  and 
Append  Text,  Polygon  Set,  Circular  Arc  3  Point  and  3  Point  Close. 
Polygons  are  limited  to  500  vertices;  Text  is  limited  to  256 
characters;  only  the  "pie  closure"  forms  of  Circular  Arc  Center 
and  Elliptical  Arc  Close  are  used. 

Eleven  GDPs  with  negative  ids  can  be  generated. 
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The  generator  does  not  use  Character  Set  Index  and  Alternate 
Character  Set  Index  nor  the  Edge  attributes.  It  uses  all  other 
attribute  elements. 

Up  to  10  line,  marker,  and  text  bundles  may  be  referenced  and  up 
to  10  pattern  table  entries  may  be  specified  and  referenced. 
Implementation  dependent  (negative  valued)  line,  marker,  and 
hatches  may  be  generated.  Implementation  dependent  fonts  are 
specified  with  indices  11  through  18.  Empty  interior  style  is 
never  generated.  Standard  hatch  indices  5  and  6  cannot  be 
generated . 

Seventy  ESCAPES  with  negative  ids  can  be  generated. 

MESSAGE  and  APPLICATION  DATA  elements  can  be  generated. 


3.2.2  AutoCAD  via  Zenographics  Metafile  Translator 

AutoCAD  DXF  files  can  be  translated  to  CGMs  via  a  Zenographics 
product,  called  Metafile.  See  the  Zenographics  description 
( section  3.2.23)  . 

The  Metafile  Elements  List  contains  an  enumerated  set  of  51 
elements,  which  is  a  superset  of  the  file  contents. 

The  file  defines  color  indexes  0-7  in  a  single  COLOR  TABLE 
element  8  RGB  triples  long:  Black,  Red,  Yellow,  Green,  Cyan, 
Blue,  Magenta,  White. 


3.2.3  Computer  Associates  International  Super Image 

Superimage  uses  the  GSS*CGM  metafile  driver.  See  the  Graphic 
Software  Systems  description  (section  3.2.7)  for  the  details. 

Absolute  line  width  is  initially  set  to  1,  but  it  can  be  changed 
later  in  the  CGM. 


3.2.4  Computer  Associates  International  (CAI)  CGM  Generator 
Library 

CAI  uses  base  technology  developed  with  the  assistance  of 
Henderson  Software.  This  CGM  generator  was  developed  for  use 
with  ISSCO  mainframe  and  minicomputer  products  like  DISSPLA  and 
TELL-A-PLAN. 

The  Metafile  Descriptor  is  minimal.  The  METAFILE  ELEMENT  LIST 
contains  DRAWING  plus  some  individual  elements  beyond  the  DRAWING 
set.  There  is  a  METAFILE  DEFAULTS  REPLACEMENT  element  that  sets 
VDC  EXTENT  to  (0,0),  (4095,4095). 
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The  Picture  Descriptor  contains  only  SCALING  MODE  and  VDC  EXTENT. 
The  VDC  extent  is  set  explicitly  to  roughly  the  aspect  ratio  of 
an  8.5  X  11  sheet  (1144  by  884).  The  SCALING  MODE  of  the 
original  files  ware  METRIC,  but  the  scale  factor  was  not  chosen 
for  a  reasonable  size  drawing.  This  element  is  scheduled  for 
repair  by  CAI  in  the  next  product  release. 


3.2.5  Genographics 

Genigraphics  developed  its  own  base  technology. 

The  Metafile  Descriptor  includes  all  elements  except  METAFILE 
DEFAULTS  REPLACEMENT,  CHARACTER  SET  LIST,  and  CHARACTER  CODING 
ANNOUNCER.  The  METAFILE  ELEMENTS  LIST  enumerates  a  superset  of 
the  elements  in  the  metafile.  The  FONT  LIST  contains  one  entry: 
''IS0646.''  All  other  descriptor  elements  have  values 

corresponding  to  CGM  defaults  except: 

COLOR  PRECISION:  16 

COLOR  INDEX  PRECISION:  16 

MAXIMUM  COLOR  INDEX:  255. 

The  Picture  Descriptor  contains  SCALING  MODE  and  COLOR  SELECTION 
MODE,  setting  CGM  default  values;  LINE  WIDTH  SPECIFICATION  MODE 
setting  ABSOLUTE;  and  VDC  EXTENT  setting  (332,0),  (32435,24076). 

Control  elements  present  are  VDC  INTEGER  PRECISION  and 
TRANSPARENCY,  setting  CGM  defaults,  and  CLIPPING  INDICATOR 
setting  ON. 

Genigraphics  uses  a  basic  Primitive  set  of  POLYLINE,  TEXT, 
POLYGON,  and  RECTANGLE  in  all  pictures  of  this  set. 


3.2.6  Graf point 

Graf point  developed  its  own  base  technology. 

In  the  Metafile  Descriptor  VDC  TYPE,  INTEGER  PRECISION,  and  INDEX 
PRECISION  set  values  that  correspond  to  the  CGM  defaults.  COLOR 
PRECISION  and  COLOR  INDEX  PRECISION  are  set  to  16  bits.  REAL 
PRECISION  is  set  to  floating  point;  the  files  do  not  contain  any 
real  operands,  so  floating  point  is  not  required.  COLOR  VALUE 
EXTENT  is  set  to  0-1000  in  each  of  the  R,  G,  and  B  components. 
The  Metafile  Elements  List  contains  an  enumerated  set  of  51 
elements,  which  is  a  superset  of  file  contents. 
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In  the  Picture  Descriptor,  SCALING  MODE  and  COLOR  SELECTION  MODE 
elements  set  values  corresponding  to  the  CGM  defaults.  LINE 
WIDTH  SPECIFICATION  MODE  and  MARKER  SIZE  SPECIFICATION  MODE  are 
set  to  ABSOLUTE.  VDC  EXTENT  is  set  to  (0,0),  (16383,16383). 

The  picture  contains  no  control  elements  other  than  VDC  INTEGER 
PRECISION,  which  contains  the  CGM  default  value. 

The  picture  starts  by  defining  color  indexes  0-15  with  a  single 
COLOR  TABLE  element,  then  many  of  the  entries  are  immediately 
redefined  one  at  a  time. 


3.2.7  Graphic  Software  System  GSS*CGM 

GSS  developed  its  own  base  technology  as  a  CGI  driver,  accessed 
through  its  GSS* CGI. 

GSS*CGM  can  generate  multiple  pictures  per  metafile. 

VDCs  are  always  16-bit  integers;  Integer,  Index,  Colour  and 
Colour  Index  Precision  is  always  16-bits;  Real  Precision  is 
always  fixed  (16,16).  Maximum  Colour  Index  is  always  255  and 
colour  extents  always  range  from  0  to  1000. 

GSS*CGM  does  not  use  Metafile  Defaults  Replacement,  Font  List, 
Character  Set  List,  and  Character  Coding  Announcer. 

Scaling  Mode  is  "abstract;"  Colour  Selection  Mode  is  "indexed;" 
and  Line  Width  and  Marker  Size  Specification  Mode  is  "absolute." 
Edge  Width  Specification  Mode  is  not  used.  Background  Colour  is 
initially  set  to  (0,0,0)  but  can  be  changed  by  the  generating 
program. 

VDC  EXTENT  is  always  (-32768,-32768,32767,32767)  for  GSS'CGM 
versions  2.12  or  earlier;  VDC  EXTENT  is  always  (0,0,32767,32767) 
for  version  2.13  or  later.  In  both  cases,  actual  VDCs  contained 
in  other  metafile  elements  always  lie  in  the  positive  (first) 
quadrant.  This  anomaly  in  early  GSS*CGMs  is  known  as  the  "1/4- 
frame  problem."  While  GSS  metafiles  are  not  syntactically 
illegal,  they  do  violate  the  spirit  of  the  CGM  standard  in  that 
the  VDC  EXTENT  is  supposed  to  represent  the  "region  of  interest" 
of  the  picture. 

All  the  Control  Elements  except  VDC  Real  Precision  can  be 
generated.  VDC  Integer  Precision  is  always  16  bits. 

Of  the  Graphical  Primitives,  only  Disjoint  Polyline,  Restricted 
and  Append  Text,  Polygon  Set,  GDP,  and  Circular  Arc  3  Point  and  3 
Point  Close  cannot  be  generated. 
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Bundles  and  ASFs  are  not  used  nor  are  the  Edge  attributes.  Of 
the  text  attributes,  Character  Spacing,  Character  Expansion 
Factor,  Text  Precision,  and  Text  Path  cannot  be  generated.  Of 
the  remaining  attributes,  only  Interior  Style,  Fill  Colour,  Hatch 
and  Pattern  Index,  and  Color  Table  are  used. 

Font  indices  1  through  100  are  meant  to  refer  to  hardware  fonts; 
font  indices  101  through  106  select  six  Hershey  software  fonts  as 
follows;  Simplex,  Complex,  Complex  Italic,  Duplex,  Triplex,  and 
Triplex  Italic. 

Private  attributes  include  Line  Type  -1  for  a  "medium  dashed" 
line;  Marker  Type  -1  for  a  "diamond";  and  Hatch  Indices  -1 
(medium-spaced  +45  degree  lines) ,  -2  (widely-spaced  +45  degree 
lines)  ,  -3  (mediiim-spaced  +45  and  -45  degree  lines)  ,  and  -4 
(widely-spaced  +45  and  -45  degree  lines) . 


3.2.8  Hewlett-Packard 

Hewlett-Packard  uses  base  technology  developed  with  the 
assistance  of  Henderson  Software  and  accessed  through  HP's 
STARBASE  software. 

HP  STARBASE  can  generate  multiple  pictures  per  metafile.  HP  also 
claims  to  be  able  to  generate  metafiles  that  conform  to  the 
TOP/BASIC  application  profile. 

The  Metafile  Descriptor  contains  most  of  the  CGM  descriptor 
elements,  lacking  only  FONT  LIST  and  CHARACTER  SET  LIST. 
However,  most  of  these  appear  with  values  corresponding  to  CGM 
defaults.  VDCs  are  always  integer,  but  a  variety  of  precisions 
can  be  generated.  Likewise,  the  other  Class  1  elements  can  be 
generated  with  a  variety  of  settings. 

Most  files  contain  a  METAFILE  DEFAULTS  REPLACEMENT  element,  which 
sets  the  VDC  INTEGER  PRECISION  to  16  bits  and  the  VDC  EXTENT  to 
(-32768,-32768),  (32767,32767). 

There  is  no  use  of  the  Edge  Width  Specification  Mode.  Background 
Colour  is  used. 

The  generator  does  not  use  Auxiliary  Colour  and  Transparency.  It 
does  use  Clip  Rectangle  and  Clip  Indicator. 

The  generator  does  not  use  Disjoint  Polyline,  Restricted  and 
Append  Text,  Cell  Array,  Rectangle,  Circle,  Circular  Arc  3  Point 
and  3  Point  Close,  Circular  Arc  Centre  and  Centre  Close,  and  the 
elliptical  elements. 

Polylines  and  Polymarkers  are  broken  into  groups  of  no  more  than 
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1024  vertices;  Polygons  and  Polygon  Sets  are  potentially 
unlimited  in  size;  Text  is  limited  to  255  characters. 

No  GDPs  can  be  generated. 

The  generator  does  not  use  Line,  Marker,  Text,  Fill,  and  Edge 
Bundles,  nor  ASFs;  Line  Width;  Character  Set  Index  and  Alternate 
Character  Set  Index;  interior  style  "hatch"  or  "pattern";  any  of 
the  Edge  attributes;  Fill  Reference  Point;  Pattern  Table  and 
Size.  It  uses  all  other  attribute  elements. 

Implementation  dependent  (negative  valued)  line  types  and  markers 
may  be  generated.  Implementation  dependent  fonts  are  specified 
with  positive-valued  indices.  Only  "hollow"  and  "solid"  interior 
style  can  be  generated. 

ESCAPE  elements  with  negative  ids  be  generated. 

MESSAGE  and  APPLICATION  DATA  elements  can  be  generated. 


3.2.9  IBM 

The  IBM  Graphics  Development  Toolkit  can  use  GSS*CGM  metafile 
driver  through  the  IBM  Virtual  Device  Interface  (VDI) .  See  the 
GSS*CGM  summary  (section  3.2.7)  for  a  complete  discussion, 
including  description  of  the  "1/4  frame  problem." 

Another  syntax  error  is  present  in  some  of  the  files;  the  data 
associated  with  ESCAPE  elements  is  incorrectly  coded.  The  data 
are  supposed  to  be  coded  as  string  data  type,  but  the  string 
length  field  is  missing  from  the  data  stored  after  the  ESCAPE 
identifier  field. 


3.2.10  Lotus  Development  Corporation 

Lotus  developed  its  own  base  technology.  There  is  only  one 
picture  per  metafile;  it  is  always  called  "PICTURE  1". 

The  Metafile  Descriptor  contains  nine  of  the  CGM  Metafile 
Descriptor  elements.  The  Metafile  Descriptor  specifies  16-bit 
integer  VDCs;  16-bit  integer,  index  precision;  (16,16)  fixed- 
point  real  precision;  colour  precision  is  not  used;  colour  index 
precision  is  always  16-bits;  maximum  colour  index  is  always  16 
and  colour  value  extent  is  not  specified.  Only  COLOR  INDEX 
PRECISION  (16)  and  MAXIMUM  COLOR  INDEX  (16)  have  non-default 
values.  There  is  no  use  of  Metafile  Defaults  Replacement,  Font 
List,  Character  Set  List,  and  Character  Coding  Announcer.  The 
METAFILE  ELEMENT  LIST  contains  an  enumerated  superset  of  the 
elements  in  the  file. 
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The  Picture  Descriptor  sets  VDC  EXTENT  to  a  maximal  horizontal 
rectangle  inscribed  in  the  0-32K  square.  Scaling  Mode  is  always 
"abstract,”  Colour  Selection  Mode  always  "indexed,"  and  Line 
Width  and  Marker  Size  Specification  Mode  always  "absolute."  Edge 
Width  Specification  Mode  and  Background  Colour  are  not  used. 

The  generator  does  not  use  Auxiliary  Colour  or  Clip  Rectangle. 
Transparency  is  always  "on"  and  Clip  Indicator  is  always  "off." 

The  generator  does  not  use  Disjoint  Polyline,  Restricted  and 
Append  Text,  Polygon  Set,  Cell  Array,  Circular  Arc  3  Point  and  3 
Point  Close. 

The  generator  does  not  use  Line,  Marker,  Text,  Fill,  and  Edge 
Bundles,  nor  ASFs;  Text  Precision  and  Path;  Character  Expansion 
Factor  and  Spacing;  Character  Set  Index  and  Alternate  Character 
Set  Index;  interior  style  "hatch"  or  "pattern";  any  of  the  Edge 
attributes;  Fill  Reference  Point;  Pattern  Table  and  Size.  It 
uses  all  other  attribute  elements. 

The  Colour  Table  element  is  not  used,  but  up  to  12  colour  indices 
are  used  (with  a  built-in  predefined  colour  table  assumed) . 

Implementation  dependent  (negative  valued)  line,  marker,  and 
hatches  may  be  generated.  Line  widths  take  on  only  five  values; 
1,  20,  80,  175,  and  275.  Implementation  dependent  fonts  are 
specified  with  indices  1  through  8.  Empty  interior  style  is 
never  generated.  One  private  line  type  (-l=mediura  dash)  can  be 
generated.  Four  illegal  marker  types  (6=dash;  7=filled  circle; 
8=filled  square;  9=filled  rectangle)  and  one  private  marker  value 
(-l=diamond)  can  be  generated.  Four  private  hatch  values  (-1 
through  -4)  and  6  illegal  hatch  values  (10-15  for  gray  scale 
fills)  can  be  generated. 

No  GDPs  are  generated  and  one  ESCAPE  with  an  id  of  -201  (Set 
Writing  Mode)  can  be  generated.  No  MESSAGE  elements  but  two 
APPLICATION  DATA  elements,  16975  and  17743,  are  used  to  flag  the 
beginning  and  end  of  closed  objects  defined  by  filled  objects  and 
their  outlines. 


3.2.11  McDonnell  Douglas  CGM  Toolkit 

McDonnell  Douglas  developed  its  own  base  technology. 

The  Metafile  Descriptor  is  close  to  that  specified  for  a  TOP 
metafile.  REAL  PRECISION  is  floating  point  (9,23).  The  METAFILE 
DEFAULTS  REPLACEMENT  sets:  VDC  REAL  PRECISION  to  floating  point 
(9,23);  TEXT  PRECISION  to  STROKE;  and  color  table  entries  2-9  as 
per  the  TOP  specification  (Red,  Green,  Blue,  Yellow,  Magenta, 
Cyan,  Black,  White)  .  There  is  a  FONT  LIST  with  4  Hershey  fonts 
as  per  the  TOP  application  profile.  The  VDC  TYPE  is  set  to  REAL 
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by  the  last  element  in  the  metafile  descriptor.  While  this  is 
legal,  it  is  unusual  to  have  it  follow  the  VDC  REAL  PRECISION 
setting  in  the  Metafile  Default  Replacements  element. 

The  file  uses  DIRECT  COLOR  SELECTION  MODE  (but  there  is  a  COLOR 
TABLE  in  the  picture  anyway) .  The  SCALING  MODE  is  METRIC,  with  a 
scale  factor  of  25.4  (converting  mm  to  inches).  Together  with 
VDC  EXTENT  of  (0,0)  to  (11.5,8.5),  this  means  a  precisely  scaled 
picture  at  normal  (US)  paper  size.  Immediately  within  the  first 
picture  body,  VDC  REAL  PRECISION  is  set  to  fixed  point  (16,16). 
The  coordinates  in  the  picture  body  are  fixed  point,  while  those 
in  the  picture  descriptor  are  floating  point. 

Generally  speaking,  McDonnell  Douglas  metafiles  contain 
partitioned  elements.  Note:  some  files  from  this  generator  have 
contained  zero-length  partitions,  which  are  legal  but  which  some 
interpreters  may  not  expect. 


3.2.12  Motorola 

Motorola  uses  base  technology  developed  by  Nova  Graphics 
International.  See  the  Nova  Graphics  summary  (section  3.2.13)  for 
more  detail. 


3.2.13  Nova  Graphics  International 

Nova  Graphics  developed  its  own  base  technology  as  a  GKS  metafile 
output  workstation  driver,  accessed  through  its  NOVA*GKS. 

The  driver  can  generate  multiple  pictures  per  metafile. 

It  can  produce  both  16-bit  and  32-bit  integer  and  both  (16,16) 
fixed  point  and  (9,23)  floating  point  real  VDCs;  8,  16,  and  32- 
bit  integer,  index  precision;  (16,16)  fixed-point  and  (9,23) 
floating  point  real  precision;  colour  and  colour  index  precision 
can  be  8,  16,  or  32  bits;  maximum  colour  index  is  always  255  and 
colour  value  extent  is  0-255. 

There  is  no  use  of  the  Character  Set  List  and  Character  Coding 
Announcer  elements. 

From  NOVA*GKS,  Scaling  Mode  is  always  "abstract;"  Colour 
Selection  Mode  is  "indexed;"  and  the  Specification  Modes  are 
always  "scaled." 

All  CGM  Control  Elements  can  be  generated. 

All  CGM  Graphical  Primitive  Elements  can  be  generated,  although 
at  present  NOVA*GKS  does  not  currently  generate  any  GDP's. 
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All  CGM  Attribute  Elements  can  be  generated,  although  at  present 
NOVA*GKS  does  not  use  Character  Set  Index  and  Alternate  Character 
Set  Index  and  does  not  generate  "continuous  alignment"  values  of 
the  TEXT  ALIGNMENT  element. 

Up  to  20  line,  marker,  and  text  bundles  may  be  referenced. 
Implementation  dependent  (negative  valued)  line,  marker,  and 
hatches  are  not  generated.  Implementation  dependent  fonts  are 
specified  with  indices  1  through  15.  Empty  interior  style  is 
never  generated.  These  standard  limits  are  changeable  by  the 
N0VA*GKS  system  installation  manager. 

N0VA*GKS  does  not  currently  generate  any  CGM  ESCAPE  elements. 
MESSAGE  and  APPLICATION  DATA  elements  can  be  generated. 


3.2.14  Pansophic  StudioWorks  version  3.00 

Pansophic  developed  its  own  base  technology  for  its  artist 
workstation  product  line. 

The  Metafile  Descriptor  sets  16-bit  integer  VDCs;  16-bit  integer, 
index  precision;  and  (16,16)  fixed-point  real  precision.  Only 
direct  colour  of  8-bits  precision  is  used;  colour  value  extent  is 
0  to  255. 

The  generator  makes  no  use  of  Metafile  Defaults  Replacement,  Font 
List,  Character  Set  List,  and  Character  Coding  Announcer. 

The  generator  makes  no  use  of  Scaling  Mode  or  Marker  Size 
Specification  Mode.  Colour  Selection  Mode  is  "direct;"  Line 
width  and  Edge  Width  Specification  Modes  are  always  "absolute." 
Background  Colour  is  used. 

None  of  the  Control  elements  are  generated. 

Only  three  Graphical  Primitive  elements  are  generated:  Polyline, 
Text,  and  Polygon. 

Only  10  of  the  35  Attribute  elements  can  be  generated  (with 
restrictions  as  described  in  the  following) :  Line  Type  (always 
l="solid") ;  Line  Width;  Line  Colour;  Text  Colour;  Character 
Height;  Interior  Style  ("hollow"  or  "solid"  only) ;  Fill  Colour; 
Edge  Type  (always  l="solid") ;  Edge  Colour;  and  Edge  Visibility 
(always  "on") . 

ESCAPE,  MESSAGE  and  APPLICATION  DATA  elements  cannot  be 
generated. 


3.2.15  Pansophic  System,  Inc.  D-PICT/GKS 
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Pansophic  distributes  ATC  GRAFPAX*GKS  and  has  used  it  to  build 
certain  layered  application  products  in  its  D-PICT  product  line, 
such  as  D-PICT/GKS  and  D-PICT/INTELLICHART,  a  stand-alone 
presentation  graphics  program.  It  uses  the  base  technology 
developed  by  ATC.  See  the  ATC  GRAFPAK*GKS  description  (section 
3.2.1)  for  details. 


3.2.16  Precision  visuals  (PVI) 

PVI  uses  base  technology  developed  by  Henderson  Software.  The 
behavior  of  the  generator  is  controlled  by  a  "software  switch" 
which  can  take  on  one  of  three  values: 

PVI  Mode  PVI  escape  functions,  special  opcodes,  and  GDPs 

are  converted  to  CGM  escape  and  GDP  elements. 
Private  values  may  occur  in  the  CGMs  so  generated. 

MAP/TOP  Conforming  Mode 

PVI  escape  functions  and  GDPs  are  NOT  mapped  to 
CGM  elements.  However,  other  private  values  are 
mapped  as  in  PVI  mode. 

MAP/TOP  Basic  Mode 

Follows  the  rules  for  Conforming  Mode  and,  in 
addition,  no  private  values  (e.g.,  proprietary 
line  types  and  hatch  styles)  are  placed  in  the 
metafile. 

The  Metafile  Descriptor  is  fairly  minimal.  It  does  contain  a 
METAFILE  DEFAULTS  REPLACEMENT  that  sets  color  indexes  2-9.  The 
METAFILE  ELEMENT  LIST  consists  of  DRAWING  and  METAFILE  DEFAULTS 
REPLACEMENT . 

All  default  precisions  and  default  colour  value  extent  are 
assumed.  There  is  no  use  of  Font  List,  Character  Set  List,  and 
Character  Coding  Announcer. 

Of  the  Picture  Descriptor  and  Control  elements,  only  Colour 
Selection  Mode,  VDC  Extent,  and  Background  Colour  can  be 
generated. 

The  following  Graphical  Primitive  Elements  can  be  generated: 
Polyline,  Polymarker,  Polygon,  and  Text. 

The  following  Attribute  Elements  can  be  generated:  Line,  Marker, 
Text,  Fill,  and  Edge  Colour;  Line  Type  and  Line  Width;  Marker 
Type;  Text  Font  Index,  Character  Expansion  Factor,  Character 
Height,  Character  Spacing,  Text  Alignment,  Text  Precision; 
Interior  Style  and  Hatch  Index;  Edge  Visibility;  and  Colour 
Table. 
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Depending  on  Mode,  ESCAPE,  GDP,  and  APPLICATION  DATA  elements  may 
be  generated.  MESSAGE  cannot  be  generated. 


3.2.17  Prime  Computer 

Prime  uses  base  technology  developed  by  ATC  and  can  generate 
multiple  pictures  per  metafile. 

The  Metafile  Descriptor  sets  16-bit  integer  VDCs;  16-bit  integer, 
index  precision;  and  (16,16)  fixed-point  real  precision.  Colour 
and  colour  index  precision  are  always  8-bits;  maximum  colour 
index  is  not  generated;  the  colour  value  extent  is  0  to  255. 

There  is  no  use  of  Metafile  Defaults  Replacement  and  Font  List. 
Character  Set  List  and  Character  Coding  Announcer  are  set  up  to 
select  ISO  646  in  8-bit  format. 

Scaling  Mode  is  always  “abstract,”  Colour  Selection  Mode  is 
“indexed,”  and  Line  Width  and  Marker  Size  Specification  Modes  are 
“scaled.”  Edge  Width  Specification  Mode  is  not  used.  Background 
Colour  is  used. 

The  generator  does  not  use  Avixiliary  Colour  and  Transparency  but 
does  use  Clip  Rectangle  and  Clip  Indicator. 

The  generator  does  not  use  Disjoint  Polyline,  Restricted  and 
Append  Text,  Polygon  Set,  Circular  Arc  3  Point  and  3  Point  Close. 
Only  the  “pie  closure”  forms  of  circular  Arc  Center  and 
Elliptical  Arc  Close  are  used. 

The  generator  uses  all  attribute  elements,  although  the  Character 
Set  Index  and  Alternate  Character  Set  Index  are  always  set  to  1 
(referring  to  ISO  646) . 

GDP  and  ESCAPE  elements  with  negative  ids  can  be  generated. 
MESSAGE  and  APPLICATION  DATA  elements  can  be  generated. 


3.2.18  Software  Publishing  Corporation  Harvard  Graphics 

Harvard  Graphics  is  built  on  top  of  GSS*CGI.  Consequently,  it 
uses  the  GSS*CGM  metafile  driver.  See  the  GSS  description 
(section  3.2.7)  for  details. 

Polylines  and  Pplygons  contain  a  maximum  of  200  vertices.  Text 
strings  contain  a  maximum  of  60  characters. 


3.2.19  Sun  Microsystems 
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Sun  uses  base  technology  developed  with  the  assistance  of 
Henderson  Software  and  accessed  through  Sun  Microsystem's  SunGKS 
software. 

SunGKS  can  generate  multiple  pictures  per  metafile. 

The  generator  uses  the  CGM  default  precisions.  Maximum  Colour 
Index  is  255.  VDC  type  is  integer  at  either  16-bit  or  32-bit 
precision.  Metafile  Defaults  Replacement  establishes  the  VDC 
INTEGER  PRECISION,  Text  Precision  as  "string,"  and  loads  the 
default  TOP  colour  table  of  254  elements,  for  indices  2  through 
255. 

Font  List  and  Character  Set  List  elements  are  not  generated,  but 
the  Character  Coding  Announcer  is  set  to  "BASIC7BIT." 

All  the  picture  descriptor  elements  are  generated.  The  VDC 
EXTENT  is  taken  from  the  GKS  Workstation  Window. 

The  generator  does  not  use  VDC  Real  Precision,  Auxiliary  Colour, 
and  Transparency.  It  does  use  Clip  Rectangle  and  Clip  Indicator. 

Because  it  is  positioned  as  a  GKS  metafile  output  workstation, 
the  generator  uses  only  five  of  the  nineteen  available  graphical 
primitives:  Polyline,  Polymarker,  Text,  Polygon,  and  Cell  Tlarray. 

Polyline,  Polymarker,  and  Polygon  are  limited  to  1024  vertices; 
Text  is  limited  to  255  characters  in  TOP  mode;  32,767  characters 
otherwise. 

No  GDPs  can  be  generated. 

The  generator  does  not  use  Character  Set  Index  and  Alternate 
Character  Set  Index;  interior  style  "empty";  any  of  the  Edge 
attributes;  and  ASFs.  It  uses  all  other  attribute  elements. 

Implementation  dependent  (negative  valued)  line  types  and  markers 
may  be  generated.  Implementation  dependent  fonts  are  specified 
with  indices  1  through  16.  A  maximum  of  eight  32x32  colored 
patterns  can  be  specified. 

No  ESCAPE  elements  can  be  generated. 

MESSAGE  but  not  APPLICATION  DATA  elements  can  be  generated. 


3.2.20  System  One  Software 

System  One  Software  developed  its  own  base  technology.  The 
generator  technology  appears  in  Presentation  Technologies 
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ImageMate  and  Kinetic  Graphics  Systems  business  graphics 
products . 

Only  one  picture  per  metafile  can  be  generated. 

The  Metafile  Descriptor  contains  most  of  the  CGM  Metafile 
Descriptor  elements. 

The  Metafile  Descriptor  sets  16-bit  integer  VDCs;  16-bit  integer, 
index  precision;  and  (16,16)  fixed-point  real  precision.  Colour 
precision  is  8-bits;  colour  index  precision  is  always  16-bits; 
maximum  colour  index  is  always  255;  and  colour  value  extents  are 
0  to  255  in  R,  G,  and  B.  Most  of  these  set  values  corresponding 
to  the  defaults  of  CGM.  The  exceptions  are  COLOR  INDEX  PRECISION 
(16)  and  MAXIMUM  COLOR  INDEX  (255). 

There  is  no  use  of  Metafile  Defaults  Replacement. 

There  is  a  FONT  LIST  element  with  2  entries,  taken  from  the  NCGA 
Integrate  88  demonstration: 

NCGA  GRAFNET: SERIF  BOLD 

NCGA  GRAFNET; SERIF  BOLD-ITALIC 

There  is  also  a  CHARACTER  CODING  ANNOUNCER  that  sets  EXTENDED  7- 
BIT.  However,  the  coding  technique  is  not  relied  upon  in  the 
metafile. 

The  Picture  Descriptor  contains  all  of  the  CGM  Picture  Descriptor 
elements.  Scaling  Mode  is  always  "abstract,”  Colour  Selection 
Mode  always  "indexed,”  and  Line  and  Edge  Width  and  Marker  Size 
Specification  Mode  always  "absolute." 

The  only  Control  element  used  is  Transparency. 

The  generator  does  not  use  Cell  Array.  Polyline,  Polymarker,  and 
Polygon  are  limited  to  370  vertices;  Text  is  limited  to  256 
characters . 

No  GDPs  are  generated. 

The  generator  does  not  use  Character  Set  Index,  Alternate 
Character  Set  Index,  Pattern  Table  and  Pattern  Size.  It  uses  all 
other  attribute  elements. 

Implementation  dependent  fonts  are  specified  with  indices  1  and 
2.  The  Font  List  element  indicates  which  fonts  are  associated 
with  the  two  indices. 

ESCAPE  elements  with  negative  ids  can  be  generated. 
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No  MESSAGE  elements  but  some  APPLICATION  DATA  elements  can  be 
generated. 


3.2.21  Teknigraphics 

Teknigraphics  metafiles  are  created  by  GRAPH-TEX,  an  application 
that  captures  a  Tektronix  TCS  data  stream  and  converts  it  to  a 
CGM  file,  using  a  relatively  early  version  of  the  GSS*CGM  driver. 

Its  Metafile  Descriptor  and  Picture  Descriptor  follow  the  GSS 
profile  presented  in  the  description  for  GSS*CGM  (section  3.2.7). 


3.2.22  Wasatch  Computer  Technology 

Wasatch  developed  its  own  base  technology. 

The  Metafile  Descriptor  contains: 

METAFILE  VERSION 
METAFILE  DESCRIPTION 
VDC  TYPE 

INTEGER  PRECISION 
INDEX  PRECISION 
COLOR  INDEX  PRECISION 
MAXIMUM  COLOR  INDEX 
METAFILE  ELEMENT  LIST. 

All  of  these  set  values  corresponding  to  CGM  defaults  (where 
there  are  defaults  specified  in  the  standard) ,  except  that 
MAXIMUM  COLOR  INDEX  is  specified  as  255  and  the  METAFILE  ELEMENT 
LIST  is  specified  as  DRAWING-PLUS-CONTROL. 

The  Picture  Descriptor  contains: 

COLOR  SELECTION  MODE 
LINE  WIDTH  SPECIFICATION  MODE 
MARKER  SIZE  SPECIFICATION  MODE 
VDC  EXTENT. 

These  also  just  set  the  values  to  the  CGM  defaults,  except  for 
VDC  EXTENT. 

There  is  a  COLOR  TABLE  that  sets  255  entries  starting  at  index  2. 
This  requires  a  color  table  to  be  257  entries  long,  if  the 
default  (interpreter-dependent)  values  of  indexes  0  and  1  are  to 
be  preserved.  All  these  color  tables  have  been  patched  so  that 
only  254  entries  are  loaded  (indices  2  through  255),  consistent 
with  the  specification  of  MAXIMUM  COLOR  INDEX  as  255. 
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3.2.23  Zenographics  Mirage,  Pixie,  et  al. 

All  Zenographics  products  use  technology  developed  by 
Zenographics . 

Only  one  picture  per  metafile  can  be  generated.  The  Metafile 
Description  does  not  identify  the  product  name,  but  rather 
specifies  the  file  name  of  the  CGM. 

Metafile  descriptor  elements  select  16-bit  integer  VDCs;  16-bit 
integer,  index  precision;  and  (16,16)  fixed-point  real  precision. 
Colour  precision  and  colour  index  precision  are  always  16-bits; 
maximum  colour  index  is  always  255  and  colour  value  extents  are  0 
to  1000. 

The  generator  makes  no  use  of  Metafile  Defaults  Replacement,  Font 
List,  Character  Set  List,  and  Character  Coding  Announcer. 

Scaling  Mode  is  always  '’abstract,”  Colour  Selection  Mode  always 
"indexed,”  and  Line  Width  always  "absolute.”  Marker  Size 
Specification  Mode  and  Edge  Width  Specification  Mode  are  not 
used. 

None  of  the  Control  elements  are  used. 

The  generator  does  not  use  Restricted  and  Append  Text,  Polygon 
Set,  Cell  Array,  Circular  Arc  3  Point  and  3  Point  Close,  Ellipse 
and  Elliptical  Arc.  Polyline,  Polymarker,  and  Polygon  are 
limited  to  480  vertices. 

No  GDPs  are  generated. 

The  generator  does  not  use  Line,  Marker,  Text,  Fill,  and  Edge 
Bundles,  nor  ASFs;  the  Marker  attributes;  Text  Precision  and 
Path;  Character  Set  Index  and  Alternate  Character  Set  Index; 
interior  style  "hatch,”  "pattern”,  and  "empty;”  Fill  Reference 
Point;  Pattern  Table  and  Size.  It  uses  all  other  attribute 
elements. 

No  ESCAPE,  MESSAGE,  or  APPLICATION  DATA  elements  can  be 
generated. 


4.0  Commercial  Implementations  .vs.Reguirements  of  MIL-D-28003 
4.1  Overview 

MIL-D-28003  (Reference  5)  establishes  the  requirements  to  be  met 
when  two-dimensional  picture  description  or  illustration  data  is 
delivered  in  the  digital  format  of  the  Computer  Graphics  Metafile 
(CGM)  as  specified  in  FIPS  PUB  128. 
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MIL-D-28003  provides  an  Application  Profile  for  metafiles, 
generators,  and  interpreters.  Only  one  level  of  conformance  is 
specified  for  metafiles  and  generators;  two  levels  (draft  and 
publication)  are  specified  for  interpreters. 

This  study  is  interested  in  the  requirements  that  must  be  met  by 
CGM  generators  in  order  to  be  deemed  "conforming  basic 
generators."  The  next  section  abstracts  from  MIL-D-28003  these 
requirements  and  discusses  which  CGM  implementations  fail  to  meet 
these  requirements.  All  of  the  specific  requirements  are 
organized  by  their  MIL-D-28003  paragraph  numbers,  except  that 
specific  requirements  in  this  docviment  are  in  sections  numbered 

4.2. x.y,  while  those  in  MIL-D-28003  will  be  in  the  section 

3.2. x.y.  Each  requirement  is  stated,  then  an  analysis  of  the 
current  state-of-the-art  is  presented.  (Note  that,  as  a 
consequence  of  the  paragraph  numbering,  not  all  sub-sub-paragraph 
numbers  will  necessarily  be  represented  within  sub-paragraph 

4.2. ) 

Other  requirements,  drawn  from  other  paragraphs  of  MIL-D-28003 
are  presented  and  discussed  in  section  4.3. 


4.2  Specific  Requirements  on  Generators 
4.2. 1.1  Delimiter  Elements 

No-ops  are  limited  in  size  to  no  more  than  32767  octets. 
Analysis:  No  CGM  observed  violates  this  limit. 


4. 2. 1.2  Metafile  Descriptor  Element  Constraints 

al.  Metafile  Description  shall  include  a  substring  briefly 
identifying  company  or  product. 

Analysis:  Most  CGMs  meet  this  requirement;  however,  those  of  ATC, 
Pansophic  (only  its  D-PICT/GKS) ,  and  Zenographics  are 
currently  deficient  in  this  respect.  This  requirement 
is  easy  to  meet. 

a2.  Metafile  Description  shall  contain  the  substring  "MIL-D- 

28003/BASIC-l." 

Analysis:  None  of  the  implementations  have  had  time  to  meet  this 
requirement;  however,  it  is  extremely  simple  to  meet. 
Furthermore,  ATC,  Genigraphics ,  Hewlett-Packard, 
McDonnell  Douglas,  Precision  Visuals,  and  Sun  all  have 
a  mode  modelled  after  "TOP/BASIC"  and  contain  such  a 
string  within  their  Metafile  Description.  This  shows 


22 


these  companies  are  at  least  aware  of  the  concepts  that 
gave  rise  to  the  CALS  application  profile. 

b.  Integer  Precision  shall  be  16. 

Analysis:  No  implementation  fails  to  meet  this  requirement, 
although  Nova  does  permit  CGMs  to  be  generated  with  32- 
bit  precision. 

c.  Real  Precision  shall  be  either  (1,16,16)  or  (0,9,23). 
Analysis:  No  implementation  fails  to  meet  this  requirement. 

d.  Index  Precision  shall  be  16. 

Analysis:  No  implementation  fails  to  meet  this  requirement, 

although  Nova  does  permit  CGMs  to  be  generated  with  32- 

bit  precision. 

e.  Color  Precision  shall  be  either  8  or  16. 

Analysis:  No  implementation  fails  to  meet  this  requirement, 

although  Nova  does  permit  CGMs  to  be  generated  with  32- 

bit  precision. 

f.  Color  Index  Precision  shall  be  either  8  or  16. 

Analysis:  No  implementation  fails  to  meet  this  requirement, 

although  Nova  does  permit  CGMs  to  be  generated  with  32- 

bit  precision. 

g.  The  Font  List,  when  present,  shall  contain  no  more  than  four 
fonts,  whose  names  are  drawn  from  the  list  of  16  Hershey  font 
names  given  in  Table  VI  of  MIL-D-28003. 

Analysis:  Most  implementations  do  not  include  Font  List.  Of  the 
five  that  do,  three  restrict  themselves  to  no  more  than 
four  names  drawn  from  the  approved  list  of  16  Hershey 
fonts. 

h.  The  Character  Set  List  must  be  present  and  shall  contain 
exactly  the  two  list  elements  (0,4/2)  and  (1,4/1). 

Analysis:  Only  two  implementations — McDonnell  Douglas  and  System 
One  Software — use  the  Character  Set  List.  However, 
neither  sets  its  parameters  to  the  proscribed  elements 
for  CALS. 

i.  The  Character  Coding  Announcer  shall  be  either  0  (BASIC  7- 
BIT)  or  1  (BASIC  8-BIT) . 
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Analysis:  All  four  implementations  that  use  the  Character  Coding 
Announcer  use  one  of  the  two  basic  values. 


4. 2. 1.3  Picture  Descriptor  Elements 

The  SCALING  MODE  metric  parameter  is  always  a  floating-point 
number  of  precision  (9,23). 

Analysis:  Both  of  the  two  implementations  that  use  SCALING  MODE 
metric  do  so  correctly,  although  an  early  release  of 
the  McDonnell  Douglas  CGM  toolkit  wrote  the  metric 
scale  factor  as  a  fixed-point  number. 


4 . 2 . 1 . 4  Control  Element 

a.  VDC  Integer  Precision  shall  be  16  or  32. 

Analysis:  No  impleme; station  fails  to  meet  this  requirement. 

b.  VDC  Real  Precision  shall  be  (0,9,23)  or  (1,16,16). 

Analysis:  No  implementation  offering  real  VDCs  fails  to  meet  this 
requirement . 


4 . 2 . 1 . 5  Graphical  Primitives 

No  GDPs  may  appear,  except  those  authorized  by  MIL-D-28003.  At 
present,  no  such  GDPs  are  authorized. 

Analysis:  Three  implementations — ATC,  Pansophic  D-PICT,  and  Prime 
will  write  GDPs  to  the  CGM.  It  is  not  known  whether 
the  Computer  Associates  CGM  toolkit  will  do  so. 


4 . 2 . 1 . 6  Attribute  Elements 

a.  Line  bundle  indices  shall  lie  between  1  and  5. 

Analysis:  Of  the  four  implementations  that  use  bundles,  none 
restrict  the  range  of  the  index  to  these  limits. 

b.  Line  types  shall  lie  between  1  and  5  or  between  -11301  and- 
11308. 

Analysis:  Ten  of  the  implementations  meet  this  requirement. 

c.  Marker  bundle  indices  shall  lie  between  1  and  5. 
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Analysis:  Of  the  four  implementations  that  use  bundles,  none 

restrict  the  range  of  the  index  to  these  limits. 

do  Marker  types  shall  lie  between  1  and  5. 

Analysis:  Six  of  the  implementations  meet  this  requirement. 

e.  Text  bundle  indices  shall  be  either  1  or  2. 

Analysis:  Of  the  four  implementations  that  use  bundles,  none 

restrict  the  range  of  the  index  to  these  limits. 

f.  Text  font  indices  shall  lie  between  1  and  4. 

Analysis:  Six  of  the  implementations  meet  this  requirement. 

g.  Character  set  indices  shall  be  either  1  or  2. 

Analysis:  Only  one  implementation — Genigraphics-uses  Character 
Set  Index  and  it  does  meet  the  requirement. 

h.  Alternate  character  set  indices  shall  be  either  1  or  2. 

Analysis:  None  of  the  implementations  use  alternate  character  set 
index. 

i.  Fill  bundle  indices  shall  lie  between  1  and  5. 

Analysis:  Of  the  four  implementations  that  use  bundles,  none 
restrict  the  range  of  the  index  to  these  limits. 

j.  Hatch  indices  shall  lie  between  1  and  6  or  between  -11401  and 

-11418. 

Analysis:  Of  the  17  implementations  that  use  hatch  index,  8  of 
them  meet  the  requirement. 

k.  Edge  bundle  indices  shall  lie  between  1  and  5. 

Analysis:  None  of  the  implementations  use  edge  bundles. 

l.  Edge  types  shall  lie  between  1  and  5. 

Analysis:  Only  the  Zenographics  Metafile  translator  from  AutoCAD 
DXF  files  to  CGM  appears  not  to  meet  this  requirement. 

m.  For  pattern  tables,  the  starting  index  shall  lie  between  1 

and  8.  Each  pattern  can  have  no  more  than  16  rows  and  16 

colvimns. 

Analysis:  Of  the  five  implementations  that  support  pattern 
tables,  none  appear  to  meet  this  requirement. 
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n.  For  color  tables,  the  starting  index  shall  lie  between  0  and 
255. 

Analysis:  No  implementations  are  known  to  violate  this 
requirement. 


4 . 2 . 1 . 7  Escape  Elements 

No  ESCAPE  elements  may  appear,  except  those  authorized  by  MIL-D- 
28003.  At  present,  three  such  ESCAPES  are  authorized.  They  have 
identifiers  -301,  -302  and  -303. 

Analysis:  No  implementations  support  the  authorized  ESCAPES,  but 
ten  implementations  do  permit  other  private  ESCAPES  to 
appear  in  the  metafile. 


4 . 2 . 1 . 8  External  Elements 

If  the  MESSAGE  element  appears,  the  "action  required"  flag  shall 
have  the  value,  "no  action  required." 

Analysis:  Of  the  11  implementations  that  permit  MESSAGE  to  appear 
in  the  CGM,  only  four  appear  to  restrict  the  value  of 
the  "action  required"  flag. 


4 . 2 . 2 . 1  Additional  Linetypes 

Eight  additional  linetypes,  with  parameter  values  -11301  through 
-11308,  are  authorized  for  use  in  CALS  basic  CGMs. 

Analysis:  There  has  not  been  time  for  this  fairly  recently  added 
requirement  to  be  supported  in  CGM  generator  products. 


4. 2. 2. 2  Additional  Hatch  Styles 

Eighteen  additional  hatch  styles,  with  parameter  values  -11401 
through  -11418,  are  authorized  for  use  in  CALS  basic  CGMs. 

Analysis:  There  has  not  been  time  for  this  fairly  recently  added 
requirement  to  be  supported  in  CGM  generator  products. 


4 . 3  Other  Requirements 
4.3.1  Encoding  Format 
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Only  the  Binary  Encoding  shall  be  used  for  conforming  basic 
metafiles. 

Analysis*.  In  the  US,  all  implementations  studied  and  almost  all 
implementations  known  can  produce  at  least  the  Binary 
Encoding.  The  workstation-level  implementations  (Sun, 
HP,  CAl)  tend  to  be  able  to  support  all  three 
encodings.  In  Europe,  the  first  encoding  supported  has 
tended  to  be  the  Character  Encoding. 


4.3.2  Physical  File  Structure 

All  CGMs  shall  be  organized  into  80-octet  records. 

Analysis:  This  requirement  is  rarely  met  by  any  implementation. 
On  PC-level  products  and  those  developed  in  C  under 
UNIX  usually  avoid  any  logical  record  structure. 
Instead,  the  binary  CGM  is  viewed  as  a  continuous 
stream  of  octets.  On  other  workstation-level  products 
(for  example,  those  running  under  VAX/VMS)  prefer  to 
have  a  logical  record  size  much  larger  than  80  octets. 
Record  sizes  of  256  and  512  are  much  more  prevalent. 
Only  those  products  with  a  ' TOP/BASIC '  mode  appear  able 
to  create  80-octet  records. 


4.3.3  Default  Text  Precision 

Either  a  TEXT  PRECISION  2  (stroke)  element  is  present  explicitly 
at  the  start  of  each  picture  or  a  METAFILE  DEFAULT  REPLACEMENTS 
element  setting  text  precision  to  2  is  present. 

Analysis:  Eight  of  the  implementations  meet  this  requirement. 

Generally,  they  are  the  same  ones  that  have  a  TOP/BASIC 
mode. 


4.3.4  Default  Color  Table 


If  color  selection  mode  is  indexed  and  if  some  color  indices  are 
selected  (used  as  attributes)  but  not  set  explicitly  by  a  COLOR 
TABLE  element,  the  intended  colors  should  be  as  specified  in  MIL- 
D-28003,  Table  VII. 

Analysis:  Thirteen  meet  this  requirement  and  eight  do  not.  The 
other  two  implementations  use  direct,  rather  than 
indexed  color. 


4.3.5  Fonts 
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No  font  names  other  than  those  listed  in  MIL-D-28003,  Table  VI, 
shall  be  allowed  to  appear  in  a  FONT  LIST  ELEMENT.  The  CGM  shall 
be  generated  either  without  any  assumptions  concerning  the  font 
metrics  of  the  selected  fonts  or  assuming  only  that  the  metrics 
match  the  metrics  of  the  Hershey  fonts  specified  in  Table  VI. 

Analysis:  Of  the  four  implementations  that  use  Font  List,  none 
meet  the  exact  details  of  this  requirement.  However, 
three  of  them  do  cite  only  Hershey  font  names,  but  the 
names  are  not  constructed  exactly  in  accordance  with 
Table  VI. 


4.3.6  Metafile  Defaults  Replacement  ^ 

This  element  shall  not  be  partitioned.  Instead,  multiple 
instances  of  this  element  should  be  used. 

Analysis:  Of  the  four  implementations  that  use  Metafile  Defaults 
Replacement  (MDR) ,  none  are  known  to  partition  the  MDR 
element.  However,  the  McDonnell  Douglas  is  known  to 
partition  other  elements  and  might  partition  this 
element. 


4.3.7  Handling  of  Out-of -range  Parameter  Values 

When  a  basic  conforming  generator  receives  (from  any  client)  a 
value  outside  the  Basic  set,  it  shall  be  handled  as  follows: 

If  the  index  is  selecting  an  attribute  (e.g., 
linetype) ,  then  the  value  shall  be  mapped  by  MODULO 
onto  the  Basic  range? 

If  the  index  is  defining  an  attribute  (e.gg  a  color 
table  entry)  ,  then  it  shall  be  ignored  if  outside  the 
Basic  range. 

Analysis:  There  is  no  way  to  determine  whether  these  requirements 
are  being  met  by  examining  the  CGM  itself.  One  would 
have  to  look  at  the  source  code  for  the  CGM  generator 
or  else  operate  the  application  generating  the  CGM. 


4.3.8  Maximum  List  Sizes  and  Lengths 

a.  Cell  arrays  may  not  exceed  1,048,576  elements  (one  1024  x 
1024  image)  in  length. 

Analysis:  Nine  implementations  can  generate  a  Cell  Array  element. 
It  is  not  known  whether  this  restriction  is  met. 
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b.  Pattern  tables  may  not  exceed  2048  elements  (eight  16  x  16 

patterns)  in  length. 

Analysis:  Of  the  five  implementations  that  use  pattern  tables, 
none  are  willing  to  limit  themselves  to  this  small  a 
number. 

c.  Color  tables  may  not  exceed  256  entries  in  length. 

Analysis:  All  implementations  appear  to  meet  this  requirement, 
although  this  information  was  not  available  for  four 
implementations . 

d.  No  point  list  array  can  exceed  1024  (X,y)  pairs. 

Analysis:  No  implementations  are  known  to  violate  this 

restriction,  although  this  information  was  not 

available  for  12  implementations. 

e.  No  data  record  may  exceed  32767  characters. 

Analysis:  No  implementation  is  known  to  violate  this  constraint. 

f.  No  other  string  parameter  may  exceed  256  characters. 

Analysis:  No  implementations  are  known  to  violate  this 

restriction,  although  this  information  was  not 

available  for  15  implementations. 


5 . 0  Conformance  Testing 

It  is  assumed  that  the  recommendations  of  section  V  are  accepted 
so  that  CGM  Certification  can  be  discussed  in  much  greater  detail 
in  this  section  of  the  report. 


5.1  Levels  of  Testing 

Four  possible  levels  of  testing  are  examined: 

Level  1:  Testing  individual  instances  of  a  CGM  for  conformance 
to  the  CGM  standard,  as  documented  in  FIPS  PUB  128, 
ANSI/X3.122,  and  ISO  8632. 

Level  2:  Testing  individual  instances  of  a  CGM  for  conformance 
to  the  CALS  CGM  Application  Profile,  as  documented  in 
MIL-D-28003. 

Level  3:  Establishing  a  Testing  Service  to  verify  conformance  of 
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a  CGM  generator  to  the  CALS  CGM  Application  Profile 
(AP)  ,  as  docvunented  in  MIL-D-28003. 

Level  4:  Establishing  a  Testing  Service  to  verify  conformance  of 
a  CGM  interpreter  to  the  CALS  CGM  AP,  as  documented  in 
MIL-D-28003. 

Level  1  testing  is  the  only  testing  that  can  be  performed  against 
the  baseline  CGM  standard,  because  the  standard  specifies  only 
the  contents  of  a  conforming  metafile;  the  standard  does  not 
specify  the  behavior  of  conforming  CGM  generators  and 
interpreters . 

The  CALS  Application  Profile  for  CGM  fills  the  gap  left  by  the 
baseline  CGM  standard,  by  specifying  the  behavior  of  conforming 
basic  generators  and  interpreters.  The  CALS  Application  Profile 
also  places  additional  conformance  requirements  on  CGMs 
themselves. 

It  is  highly  preferable  that  the  testing  capabilities  be 
developed  in  the  order  given  by  the  level  number  because  a  level 
3  testing  service  depends  on  having  a  level  2  testing  capability 
and  level  2  testing  depends  on  having  a  level  1  testing 
capability.  Strictly  speaking,  a  level  4  testing  service  could 
be  established  independently  of  the  other  three  levels  of 
testing;  however,  having  those  other  testing  capabilities 
available  first  will  make  it  easier  to  verify  that  the  CGMs  used 
to  test  the  behavior  of  CGM  interpreters  are  indeed  conforming 
CGMs. 


5.2  Overview  of  Required  Tasks 

References  8  and  9  present  a  global  model  of  the  overall 
Conformance  Testing  Policy  and  Procedures  that  can  be  applied  to 
Graphics  Standards.  Tasks  can  be  categorized  as  either 
administrative  or  technical.  In  the  context  of  Conformance 
Testing,  there  are  three  main  participants:  the  certification 
body,  the  testing  laboratory,  and  the  client. 

For  a  successful  Testing  Service  to  be  established,  one  must 
design  and  carry  out  a  series  of  tasks  related  to  supporting  each 
role  expected  of  the  main  participants.  In  the  remainder  of  this 
section,  the  general  tasks  that  must  be  accomplished  during  the 
start-up  phase  are  described.  Also  described  is  how  these 
general  tasks  can  be  particularized  to  the  situation  relating  to 
the  testing  of  MIL-D-28003  and  roughly  estimate  the  resources 
required  to  accomplish  each  task. 

It  should  be  noted  that  the  accomplishment  of  all  the  tasks 
discussed  below  would  constitute  an  extremely  large  level  of 
effort  by  NIST/NCTL,  far  beyond  the  scope  of  present  resources. 
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A  significant  increase  in  CALS  funding  would  be  needed  for 
NIST/NCTL  to  hire  additional  personnel  for  this  effort. 

The  maintenance  phase  of  Conformance  Testing  is  not  addressed  in 
this  report.  There  are  on-going  requirements  to  maintain  the 
test  methods  and  oversee  the  operation  of  the  testing 
laboratories,  but  it  is  beyond  the  scope  of  this  effort  to 
estimate  the  costs  associated  with  the  long-term  maintenance  of  a 
CGM  Conformance  Testing  program.  Consequently,  the  resource 
estimates  in  the  paragraphs  marked  Estimated  Effort  generally 
cover  only  the  start-up  costs  to  be  incurred  within  the  first  12 
months . 

The  next  section  elaborates  on  the  tasks  associated  with  the 
operation  of  the  Testing  Laboratory.  These  are  the  tasks  that 
the  Government  is  most  likely  to  obtain  from  a  variety  of 
external  sources;  the  other  tasks  could  be  accomplished  to  a 
large  degree  using  internal  resources.  Note  that  development  of 
the  Test  Method,  especially  the  creation  of  the  Test  Requirements 
document,  the  Test  Suite  and  any  testing  tools,  need  not  be  done 
by  a  Testing  Laboratory  itself.  Indeed,  because  it  is  desirable 
that  the  test  suite  and  testing  tools  be  based  on  already 
existing  software,  it  is  highly  likely  that  the  most 
cost-effective  approach  will  be  to  procure  these  components  of 
the  Test  Method  from  third-party  sources,  not  presently 
affiliated  with  any  Testing  Laboratory. 


5.2.1  Scope  of  the  Testing  Effort 

As  noted  previously,  the  CALS  Application  Profile  for  CGM  (MIL- 
D-28003)  makes  statements  about  conforming  basic  metafiles, 
conforming  basic  generators,  and  conforming  basic  interpreters. 
The  notion  of  issuing  validation  certificates  should  be  applied 
only  to  the  testing  of  conforming  generators  and  conforming 
interpreters  (level  3  and  level  4  testing)  ,  and  not  to  the 
testing  of  specific  instances  of  CGMs  (level  1  and  level  2 
testing) . 

Nevertheless,  many  tasks  associated  with  the  operation  of  the 
Certification  Body  must  be  accomplished  at  least  in  part  if  one 
seeks  to  establish  a  credible  level  1  and  level  2  testing 
program.  Consequently,  it  is  highly  desirable  that  one  develop 
and  make  available  to  industry  an  automated  testing  tool  that  can 
check  each  instance  of  a  purported  conforming  basic  metafile  and 
determine  whether  it  indeed  is  conforming. 

Separate,  but  related,  efforts  will  be  required  to  establish 
Conformance  Testing  Programs  for  CALS  basic  conforming  generators 
(level  3  testing)  and  for  CALS  basic  conforming  interpreters 
(level  4  testing) .  In  particular,  although  administrative 
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procedures  and  processes  may  be  shared,  the  test  methods  are 
quite  different. 


5.2.2  Initial  Tasks  Associated  With  Certification  Body 
Responsibilities 

In  the  task  estimates  that  follow,  the  following  notation  is 
used,  m;n;o;p  man-weeks,  to  mean  that  m  man-weeks  are  required  to 
implement  level  1  testing,  an  additional  n  man-weeks  are  required 
for  level  2  testing,  an  additional  o  man-weeks  are  required  for 
level  3  testing,  and  an  additional  p  man-weeks  are  required  for 
level  4  testing. 

TCBl.  Develop  the  overall  conformance  testing  program  policies 
and  procedures. 

Relatively  informal  policies  and  procedures  are  required  for 
level  1  and  level  2  testing.  It  is  presumed  that  the  detailed 
procedures  could  be  abstracted  directly  from  References  8  and  9. 
The  ISO  work  is  especially  applicable  to  the  CGM  standard. 
However,  testing  to  MIL-D-28003  requires  further  detailing  of  the 
processes  and  procedures ,  because  one  needs  to  take  into 
consideration  the  maintenance  and  update  cycle  associated  with 
MIL-D-28003  itself,  in  addition  to  any  changes  in  the  baseline 
CGM  standard  as  represented  by  FIPS  PUB  128. 

Estimated  Effort :  1.5;0.5;2.0;1.0  man-weeks . 

TCB2.  Approve  the  design  of  the  test  method,  when  it  has  been 
developed. 

In  fact,  two  complete  test  methods  must  be  approved — one  for 
generators  and  one  for  interpreters.  In  addition,  the  design  of 
the  test  method  for  interpreters  must  be  structured  to  handle 
implementations  that  purport  to  meet  only  the  "draft”  conformance 
level  as  well  as  those  that  aim  at  meeting  the  "publication" 
conformance  level.  The  test  method  design  for  generators  applies 
to  level  1,  2,  and  3  testing. 

NIST  has  recommended  that  a  test  method  for  generators  be 
developed  prior  to  a  test  method  for  interpreters. 

Estimated  Effozrt:  0.5;0.5;2.0;2.0  man-weeks. 

TCB3.  Conduct  a  "trial  use"  implementation  phase,  involving  a 
"field  test"  of  the  test  method. 

The  provisions  of  clause  7.2.1,  Reference  9,  "Acceptance  of  the 
Test  Suite,"  can  be  applied.  This  clause  specifies  an  "alpha" 
testing  period,  where  the  test  method  is  used  by  its  developers 
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and  the  certification  body  (if  desired)  ,  and  a  "beta"  testing 
period,  where  potential  clients  test  the  test  method. 

"Trial  use"  of  generator  and  interpreter  test  methods  can  be 
carried  out  independently  of  one  another. 

Estimated  Effort:  1;1;2;6  man-weeks  for  the  alpha  phase. 

1;1;2;4  man-weeks  for  the  beta  phase. 

TCB4.  Approve  ciny  revisions  to  the  test  method  as  a  result  of 
the  "field  test." 

The  certification  body  and  the  testing  laboratory  should  work 
together  to  decide  upon  the  changes  necessitated  by  the  "field 
test . " 

Estimated  Effort:  man-weeks  for  the  alpha  phase  and 

2;2;2;2  man-weeks  for  the  beta  phase. 

TCB5.  Approve  the  test  report  form. 

The  provisions  of  clause  6.2.2,  Reference  9,  "Test 
Specifications,"  and  clause  7.3,  "Adoption  of  a  Test  Report 
Format,"  can  be  applied. 

Estimated  Effort:  1;1;1;1  man-weeks. 

TCB6.  Develop  the  validation  procedures. 

As  specified  in  section  4. IB  of  Reference  8,  the  validation 
procedures  "define  the  steps  and  criteria  by  which  FIPS 
conformance  testing  is  to  be  done  in  order  for  a  validation 
certificate  to  be  issued."  The  provisions  of  clause  7. 2. 2. 4, 
Reference  9,  "On-site  Testing  Procedures,"  can  be  applied. 

Estimated  Effort:  0;0;1;2  man-weeks.  No  formal  certification  is 
performed  with  level  1  and  level  2  testing. 

TCB7 .  Determine  and  document  the  criteria  upon  which  a 
validation  certificate  will  be  issued. 

The  provisions  of  clause  8.2,  Reference  9,  "Organizational 
Procedures  for  Certification,"  and  clause  9.2,  "Conformance 
Requirements,"  can  be  applied. 

Estimated  Effort:  0;0;1;3  man-weeks.  No  formal  certification  is 
performed  with  level  1  and  level  2  testing. 

TCB8.  Design  the  validation  certificate. 

Acceptability  to  the  international  community  should  be  a  high- 
priority  consideration  at  this  stage.  One  should  examine 
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existing  models,  both  within  the  graphics  community  (e.g.,  GKS) 
and  outside  of  it  (e.g.,  OSI  interchange  standards). 

Estimated  Effort:  0;0;1;1  man-weeks.  No  formal  certification  is 
performed  with  level  1  and  level  2  testing. 

TCB9.  Establish  and  document  the  criteria  for  accreditation  of 
the  testing  laboratory. 

The  provisions  of  clause  8. 1.1.1,  Reference  9,  "Certification 
Body  and  Accreditation  Body,"  and  clause  8.1.2,  "Test  Method 
Administration,"  can  be  applied.  Experience  with  setting  up  the 
GKS  Testing  Service  should  also  be  directly  applicable. 

Estimated  Effort:  0;0;4;4  man-weeks.  No  formal  certification  is 
performed  with  level  1  and  level  2  testing  so  no  accreditation  of 
Testing  Laboratories  is  required. 

TCBIO.  Conduct  initial  proficiency  testing  of  laboratory 
personnel . 

Overseeing  "dry  runs"  by  laboratory  personnel  is  the  best  method 
of  judging  their  proficiency.  Prior  to  that,  personnel  should  be 
trained  on  the  procedures  to  be  followed  and  their  understanding 
of  the  importance  of  documentation  (Ref.  9,  clause  1.2. 2.1)  and 
confidentiality  (Ref.  9,  clause  7. 2. 2. 6).  On  a  more  elaborate 
.scale,  one  could  design  a  written  and  oral  examination  that 
laboratory  personnel  could  be  required  to  pass. 

Estimated  Effort:  0;0;6;14  man-weeks.  No  formal  certification 
is  performed  with  level  1  and  level  2  testing  so  no  training  of 
Testing  Laboratories  personnel  is  required. 

TCBll.  Verify  that  the  testing  laboratory *s  recordkeeping  system 
is  adequate  and  in  accordance  with  the  testing  procedures. 

The  provisions  of  clause  1 .2.2.1 ,  Reference  9,  "Documentation," 
and  clause  7. 2. 2. 8,  "Archiving  of  Records,"  apply.  Experience 
with  setting  up  the  GKS  Testing  Service  should  also  be  directly 
applicable. 

Estimated  Effort:  0;0;2;2  man-weeks.  No  formal  certification  is 
performed  with  level  1  and  level  2  testing  so  no  checking  of  the 
Testing  Laboratories'  records  is  required. 

TCB12.  Develop  procedures  for  resolving  disputes.  Establish 
Control  Board. 

The  provisions  of  clause  7.2.2. 1,  Reference  9,  "Control  Board," 
and  clause  7. 2. 2. 2,  "Control  Board  Procedures,"  apply. 
Experience  with  setting  up  the  GKS  Control  Board  should  also  be 
directly  applicable. 
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A  combined  Control  Board  for  CGM  (covering  both  generators  and 
interpreters)  is  recommended.  If  the  Control  Board  is  mainly 
concerned  with  testing  to  ISO  8632;  it  is  unclear  who  will 
interpret  issues  deriving  directly  from  MIL-D-28003.  This  could 
be  a  very  "sticky”  matter;  consequently,  it  needs  to  be  discussed 
very  early  in  the  start-up  phase  and  needs  to  be  under  constant 
discussion  until  a  resolution  satisfactory  to  all  parties  can  be 
obtained. 

Estimated  Effort:  3;1;2;3  man-weeks,  including  two  or  three 

international  meetings  to  discuss  establishment  of  the  CGM 
Testing  Service  and  the  CGM  Control  Board. 

TCB13.  Acquire  rights  to  and  estcdilish  fees  for  products  and 
services  associated  with  the  Conformance  Testing  program. 

Reference  9  (In  particular,  clauses  7.4,  8. 1.1.1,  8. 1.1.6,  and 

8.2)  contains  guidance  regarding  the  licensing  of  test  method 
materials  and  the  fees  that  can  be  charged  for  products  and 
services. 

Estimated  Effort:  2;0.5;1;0.5  man-weeks,  including  any  legal 

review  necessary  to  approve  the  language  required  to  implement 
any  "agreements  in  principle"  negotiated  between  the  Government 
and  private  developers. 


5.2.3  Initial  Tasks  Associated  With  Testing  Laboratory 
Operations 

No  resource  estimates  shall  be  given  for  the  tasks  listed  in  this 
section  or  in  the  next  section.  Only  a  brief  discussion  of  each 
task  will  occur  here.  Much  more  detailed  discussions  and 
estimates  are  provided  in  section  5.3  below. 

Remember  that  these  tasks  would  most  likely  be  developed  by 
third-party  suppliers,  not  Testing  Laboratory  personnel;  the 
results  of  the  tasks  would  be  used  by  Testing  Laboratory 
personnel  to  perform  CGM  validation  and  certification. 

TTLl.  Design  the  overall  test  method. 

For  the  generator  (levels  1,  2,  and  3  testing),  the  test  method 
will  depend  on  using  a  reference  implementation  of  a  CGM 
interpreter.  A  level  3  testing  service  would  require  a 
representative  sample  of  CGMs  output  by  the  generator-under-test 
to  be  tested  for  conformance  to  the  conforming  basic  metafile 
provisions  of  MIL-D-28003. 

For  the  interpreter  (level  4  testing) ,  the  test  method  will 
include  the  preparation  of  a  set  of  test  CGMs,  with  associated 
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hard-copy  and  documentation.  The  results  of  interpreting  the 
CGMs  in  the  Test  Set  by  the  interpreter-under-test  will  be 
compared  visually  with  the  reference  hard-copy  and  conformance 
established  according  to  documented  criteria. 

TTIi2.  Document  what  parts  of  the  stcuidard  are,  in  fact,  to  be 
tested  by  the  test  suite.  Similarly,  document  those  areas  that 
are  not  to  be  tested  by  the  test  suite. 

The  provisions  of  clause  6.1.1,  Reference  9,  "Determination  of 
Testing  Domain,"  and  clause  6.2.1,  "Test  Requirements  Document," 
apply. 

Most  of  this  work  needs  to  be  completed  even  before  the  remaining 
tasks  for  level  1  testing  can  be  accomplished. 

TTL3.  Develop  the  test  suite. 

The  provisions  of  clause  6.1.2,  Reference  9,  "Structure  of  a  Test 
Suite,"  and  clause  6.1.4,  "Portability  of  a  Test  Suite,"  apply. 

TTIi4.  Develop  any  required  support  tools. 

The  provisions  of  clause  6.1.5,  Reference  9,  "Language  Bindings 
and  Encodings,"  apply. 

TTL5.  Design  the  test  report,  both  content  and  presentation 
layout. 

The  provisions  of  clause  6.2.2,  Reference  9,  "Test 

Specifications,"  and  clause  7.3,  "Adoption  of  a  Test  Report 
Format,"  apply. 

TTL6.  Develop  test  procedures,  including  instructions  for 
installing  euid  executing  the  test  suite. 

The  provisions  of  clause  6.2.2,  Re'^'erence  9,  "Test 

Specifications,"  clause  6.2.3,  "Test  Suite  and  Documentation," 
clause  7. 2. 2. 4,  "On-site  Testing  Procedures,"  and  clause  7. 2. 2. 8, 
"Checklist,"  apply. 

TTL7.  Document  how  to  evaluate  the  test  results  for  accuracy 
and  completeness. 

The  provisions  of  clause  6.2.2,  Reference  9,  "Test 

Specifications,"  and  clause  7. 2. 2. 5,  "Preparation  of  the  Test 
Report , "  apply . 

TTL8.  Participate  in  a  "field  test"  of  the  testing  method  for 
piiblic  review  and  comment  during  a  "trial  use"  period. 
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The  provisions  of  clause  7.2.1,  Reference  9,  "Acceptance  of  the 
Test  Suite , "  apply . 


TTL9.  Refine  the  test  method  as  a  result  of  the  "trial  use" 
period. 

Collaborate  with  the  Certification  Body  and/or  Accreditation  Body 
to  arrive  at  consensus  on  what  changes  need  to  be  made. 

TTLIO.  Develop,  negotiate,  and  approve  appropriate  legal 
documents  and  procedures  that  protect  both  the  rights  of  the 
Government  and  the  test  method  owner  in  accordance  with  the 
provisions  of  Reference  8. 

In  particular,  license  agreements  with  the  Government,  the 
Certification  Body,  other  Testing  Laboratories,  and  the  clients 
need  to  be  drafted  and  approved  for  use. 

The  provisions  of  clause  7.4,  Reference  9,  "Issue  of  Licenses," 
apply. 

TTLll.  Develop  change  control  emd  maintencmce  procedures  for  the 
test  method. 

The  provisions  of  clause  6.1.3,  Reference  9,  "Maintenance  of  a 
Test  Suite,"  and  clause  7.4,  "Maintenance  Requirements,"  apply. 


5.2.4  Initial  Tasks  Associated  With  Client  Responsibilities 

These  tasks  are  applicable  only  to  level  3  and  level  4  testing, 
because  establishing  a  formal  testing  service  is  not  appropriate 
for  level  1  and  level  2  testing  (the  testing  of  individual  CGMs) . 

TCLl.  Specify  and  document  the  steps  that  a  client  shall  follow 
in  order  to  have  a  product  tested  and  to  obtain  a  validation 
certificate. 

The  provisions  of  clause  7. 2. 2. 3,  Reference  9,  "Applying  for 
Testing,"  apply. 

TCL2 .  Specify  and  document  the  statements  or  information 
provided  by  the  client  when  applying  for  conformance  testing 
leading  towards  a  validation  certificate. 

In  particular,  a  questionnaire  needs  to  be  developed  for  clients 
to  fill  out  and  submit  with  their  application  for  testing.  The 
questionnaire  will  require  specifics  about  the  environment  on 
which  their  software  runs  as  well  as  about  the  exact  CGM 
elements,  types,  and  precisions  handled  by  their  implementation. 
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5.3  E)et:ailed  Task  Descriptions 


This  section  elaborates  on  the  tasks  associated  with  the 
operation  of  the  Testing  Laboratory.  Remember,  these  are  the 
tasks  that  the  Government,  represented  by  the  Certification  Body, 
is  most  likely  to  obtain  from  a  variety  of  external  sources. 
Typically,  they  will  not  be  performed  by  Testing  Laboratory 
personnel . 


5.3.1  Task  Notation 

As  noted  previously,  separate,  but  related,  efforts  will  be 
required  to  establish  Conformance  Testing  Programs  for  CALS 
conforming  basic  generators  and  for  CALS  conforming  basic 
interpreters.  In  particular,  although  administrative  procedures 
and  processes  may  be  shared,  the  test  methods  are  quite 
different. 

The  following  sections  address  the  tasks  separately — once  for 
testing  generators  (the  Task  numbers  will  have  the  suffix  G)  and 
once  for  testing  interpreters  (the  Task  numbers  will  have  the 
suffix  I) .  In  addition,  where  the  tasks  have  been  subdivided  in 
order  to  provide  more  detail,  lowercase  Roman  letters  are  used  as 
a  further  suffix. 


5.3.2  Testing  for  Conforming  CGH  Generators 
TTLIG.  Design  the  overall  test  method. 

For  the  generator,  the  test  method  will  include  the  use  of  a 
reference  implementation  of  a  CGM  interpreter.  A  representative 
sample  of  CGMs  output  by  the  generator-under-test  will  be  tested 
for  conformance  to  the  conforming  basic  metafile  provisions  of 
MIL-D-28003 . 

Two  levels  of  testing  could  be  performed — one  syntactic  and  one 
semantic.  For  syntactic  testing,  one  wants  to  develop  a  process 
that  reads  a  CGM  and  automatically  produces  a  Conformance  Report. 
For  example,  one  should,  at  a  minimum: 

verify  that  each  element  in  the  CGM  is  well-formed 
(that  is,  encoded  correctly  and  containing  the  correct 
number  of  parameters  of  the  correct  data  type) ; 

check  for  the  correct  ordering  of  the  elements;  and 

verify  that  constraints  on  parameter  values  are 
observed. 
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One  approach  towards  testing  for  semantic  correctness  involves 
the  use  of  a  full  "reference  implementation"  of  a  CGM  interpreter 
that  produces  a  graphical  display  that  could  be  compared  with  a 
hardcopy  of  the  picture  supplied  by  the  client  for  the  CGM-under- 
test.  Even  if  a  CGM  is  syntactically  correct,  it  might  not 
contain  the  appropriate  set  of  CGM  elements  necessary  to  portray 
the  intended  picture.  This  stage  of  testing  would  require  human 
evaluation  and  cannot  be  automated.  The  quality  of  the  resulting 
Conformance  Report  is  directly  related  to  the  quality  of  the 
reference  implementation  and  the  skill  of  the  human  evaluator. 

Anorher  possible  approach  towards  testing  for  semantic 
correctness  would  require  clients  to  specify,  in  some  semi-formal 
language  or  on  some  structured  questionnaire,  all  the  elements 
they  intended  to  place  in  each  of  their  test  CGMs.  The  semantic 
analyzer  would  disassemble  the  CGM-under-test  and  compare  the 
elements  observed  with  the  client's  declaration  as  to  what  was 
intended  to  be  stored  in  the  CGM.  This  system  could  be 

automated,  but  places  a  substantial  burden  on  the  client.  Work 
supporting  this  kind  of  approach  is  still  at  the  research  stage; 
this  approach  will  not  be  considered  further  as  being  feasible 
for  CGM  generator  testing. 

Estimated  Effort:  Two  man-weeks  to  decide  how  much  semantic 

testing — if  any— should  be  performed,  to  decide  what  method  of 
testing  should  be  used,  and  to  document  in  detail  the  test  method 
selected  for  generators.  This  task  should  be  performed  once  for 
all  three  levels  of  testing  generators. 

TTL2G.  Document  what  parts  of  the  standard  are,  in  fact,  to  be 
tested  by  the  test  suite.  Similarly,  docximent  those  areas  that 
are  not  to  be  tested  by  the  test  suite. 

A  Test  Requirements  Document  must  be  developed  from  two  sources: 
the  CGM  standard  itself  (ANSI/X3.122 — FIPS  PUB  128)  and  from  the 
CALS  AP  for  CGM  (MIL-D-28003) .  The  requirements  document  will  be 
used: 

1.  to  specify  all  the  tests  that  must  be  carried  out  by 
the  syntactic  analyzer  to  verify  the  conformance  of  any 
particular  CGM-under-test,  and 

2.  to  specify  the  number  and  contents  of  the  collection  of 
CGMs  to  be  provided  by  a  client  for  testing  in  order 
for  the  client's  generator  product  to  be  certified  as  a 
conforming  generator. 

In  each  area,  one  will  have  to  determine  whether  the  tests  should 
be  performed  in  any  particular  order  and  which  requirements  are 
more  important  for  testing  purposes.  This  substantial  task  can 
be  subdivided  into  smaller  tasks  to  simplify  the  job  of 
estimating  the  work  involved. 
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TTli2Ga.  Dociment  const:raint:s  on  synt:ax,  ordering  of  elements, 
parameter  ranges,  etc.  needed  for  correct  implementation  of  a 
syntax  analyzer  to  verify  generator  conformance  to  FIPS  PUB  128. 

Estimated  Effort:  Three  man-weeks  towards  level  1  testing. 

TTL2Gb.  Document  constraints  on  synteuc,  ordering  of  elements, 
parameter  ranges,  etc.  needed  for  correct  implementation  of  a 
syntax  analyzer  to  verify  generator  conformance  to  MIL-D-28003. 

Estimated  Effort:  0.5  man-weeks  towards  level  2  testing,  because 
the  results  documented  in  section  111(4.0)  above  can  be  used  as  a 
starting  point,  although  they  need  to  brought  up-to-date  to 
reflect  the  final  draft  of  MIL-D-28003. 

TTL2GC.  Dociiment  the  range  of  test  CGMs  needed  from  the  client 
to  verify  generator  conformance  to  FIPS  PUB  128. 

Estimated  Effort:  Two  man-weeks  towards  level  3  testing. 

TTIi2Gd.  Document  the  range  of  test  CGMs  needed  from  the  client 
to  verify  generator  conformance  to  MIL-D-CGM. 

Estimated  Effort:  An  additional  1.5  man-weeks  towards  level  3 

testing,  because  the  results  dociunented  in  section  111(4.0)  above 
can  be  used  as  a  starting  point,  although  they  need  to  brought 
up-to-date  to  reflect  the  final  draft  of  MIL-D-CGM. 

TTL3G.  Develop  the  test  suite. 

Any  computer  programs  written  to  automatically  analyze  or 
interpret  CGM  files  and  associated  descriptions  shall  be  written 
in  a  standard  high-level  programming  language.  All  machine- 
dependent,  language-  dependent,  and  operating-system-dependent 
functionality  shall  be  isolated  into  we 11 -documented  modules. 
Variations  among  systems  shall  be  parameterized  wherever  it  is 
feasible  to  do  so. 

Reference  9  suggests  that  the  output  of  each  test  case  shall  give 
the  tester  the  possibility  to  trace  and  easily  understand  the 
results  either  by  looking  at  the  report  file  or  the  source  code. 
Because  the  test  cases  are  binary  encoded  CGMs,  a  hximan  cannot 
understand  their  contents  by  direct  examination.  Consequently,  a 
utility  task  that  disassembles  and  prints  the  contents  of  a  CGM 
may  need  to  be  developed. 

Programs  shall  be  written  to  be  small  enough  to  be  run  on 
Personal  Computer  class  machines. 

TTL3Ga.  Develop  the  syntax  analyzer  corresponding  to  the  FIPS 
requirements . 
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This  tool  is  needed  for  level  1  testing. 

Estimated  Efforts  Eight  man-weeks  if  one  already  has  a  baseline 
implementation  to  build  upon.  The  principal  effort,  would  involve 
checking  for  completeness,  implementing  the  reporting  formats 
required,  and  testing.  Without  a  baseline  implementation,  this 
could  take  from  26  to  52  man-weeks. 

TTL3Gb.  Augment  the  syntax  amalyzer  to  additionally  check  for 
the  constraints  specified  in  MlL-D-28003. 

This  augmentation  of  the  basic  tool  is  needed  for  level  2 
testing. 

Estimated  Effort:  Three  man-weeks  once  Task  TTL3Ga  has  been 

completed. 

TTL3GC.  Develop  a  graphical  interpreter  that  can  display  any 
CALS  conforming  basic  CGM  and  that  meets  at  least  the  Draft 
Quality  interpreter  requirements  of  MIL-D-28003. 

This  task  could  be  implemented  to  support  individual  CGM  testing 
at  level  2  or  the  task  could  be  deferred  to  testing  at  level  3 . 

Estimated  Effort:  Twelve  man-weeks  if  one  already  has  a 
baseline  implementation  to  build  upon.  The  principal  effort 
would  involve  incorporating  the  Minimum  Quality  interpreter 
requirements  of  MIL-D-28003,  implementing  the  reporting  formats 
required,  and  testing.  An  additional  twelve  man-weeks  will  be 
required  to  upgrade  a  Draft  Quality  interpreter  to  meet  the  full 
Publication  Quality  requirements  of  MIL-D-28003. 

The  estimated  effort  is  heavily  dependent  upon  the  capabilities 
of  the  underlying  graphics  system  used  to  render  the  picture. 
Portability  considerations  would  suggest  GKS,  but  some  of  the 
MIL-D-28003  requirements  exceed  the  capabilities  of  most  GKS 
systems.  Consequently,  the  interpreter  might  have  to  do 
extensive  emulation  (e.g.,  of  line  types,  the  CALS  hatch  styles, 
and  fonts) . 

Without  a  baseline  implementation  to  build  upon,  this  effort 
could  easily  take  from  52  to  104  man-weeks. 

TTL4G.  Develop  any  required  support  tools. 

The  testing  personnel  and  the  client  personnel  need  a  reliable 
utility  program  that  will  print  out,  in  a  convenient  formatted 
fashion,  the  contents  of  a  given  CGM-under-test .  This  task 
should  be  implemented  to  support  individual  CGM  testing 
at  levels  1  and  2. 
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Estimated  Effort:  Eight  man-weeks  if  one  already  has  a  baseline 
reference  implementation  to  build  upon.  The  principal  effort 
would  involve  improving  the  documentation  to  meet  Government 
standards,  revising  the  reporting  formats  to  meet  Conformance 
Testing  standards,  and  testing  of  the  tool. 

The  estimated  effort  is  heavily  dependent  upon  the  initial 
parsing  and  reporting  capabilities  of  the  baseline  reference 
implementation,  if  one  can  be  found. 

Without  a  baseline  implementation  to  build  upon,  this  could 
easily  take  from  20  to  40  man-weeks. 

TTL5G.  Design  the  test  report,  both  content  and  presentation 
layout. 

Reference  9,  clause  6.2.2,  suggests  that  the  test  report  shall 
provide  a  summary  of  tests  passed.  In  the  case  of  failure,  a 
detailed  description  of  errors  (parameter  values  and  other 
relevant  information) ,  helpful  information  for  the  implementor  to 
determine  errors,  and  a  reference  to  the  standard  shall  be 
provided.  Clause  7.3  further  requires  that  ISO  Guide  45  shall  be 
consulted  and  that  the  test  report  format,  as  a  minimum,  shall 
contain  the  following  information: 

description  of  product  under  test, 
description  of  the  test  environment. 

a  summary  giving  numbers  of  test  cases  passed,  failed, 
withdrawn,  and  total  cases. 

-  full  details  for  each  test  case  which  failed, 
a  description  of  any  unexpected  results. 

Test  report  formats  for  each  of  the  test  suite  programs  and  any 
support  tools  will  have  to  be  designed. 

Estimated  Effort:  One  man-week  for  the  syntactic  checker  used  in 
level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  one 
man-week  for  the  semantic  checker  proposed  for  level  2  or  level  3 
testing  (see  task  TTL3Gc) . 

TTL6G.  Develop  test  procedures. 

Extensive  documentation  for  both  testing  personnel  and  the  client 
is  required. 

TTL6Ga.  Develop,  document,  and  test  procedures  for  installing 
each  of  the  testing  programs  and  utility  tools. 

Estimated  Effort:  0.5  man-weeks  for  the  syntactic  checker  used 
in  level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  one 
man-week  for  the  semantic  checker  proposed  for  level  2  or  level  3 
testing  (see  task  TTL3Gc) . 
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TTL6Gba  Develop,  document:,  and  t:esb  an  operator  script:  for  each 
type  of  test  to  be  performed. 

Estimated  Effort;  One  man-week  for  the  semantic  checker  proposed 
for  level  2  or  level  3  testing.  No  formal  scripts  are  required 
for  level  1  or  level  2  syntactic  testing. 

TTL6GC.  Develop  and  document  maintenance  procedures. 

Estimated  Effort:  One  man-week  for  the  syntactic  checker  when 
used  for  level  3  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  one 
man-week  for  the  semantic  checker  when  used  for  level  3  testing 
(see  task  TTL3Gc) .  No  formal  maintenance  is  required  for  level  1 
or  level  2  syntactic  testing. 

TTL6Gd.  Develop  and  document  procedures  for  on-site  modification 
of  the  tests. 

Estimated  Effort:  0.5  man-weeks  for  the  syntactic  checker  when 
used  for  level  3  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  0.5 
man-weeks  for  the  semantic  checker  when  used  for  level  3  testing 
(see  task  TTL3Gc} .  No  formal  on-site  modification  procedures  are 
required  for  level  1  or  level  2  syntactic  testing. 

TTL6Ge.  Develop  and  document  procedures  regarding  the  retention 
of  hard  copy,  the  keeping  of  journals,  and  the  verification  that 
the  generator-under-test  represents  the  product  for  which  a 
certification  is  being  requested. 

Estimated  Effort:  One  man-week  for  level  3  testing. 

TTL6Gf.  Develop  checklists  of  materials  to  take  for  on-site 
testing  and  checklists  of  materials  to  sad  after  testing  is 
completed. 

Estimated  Effort;  One  man-week  for  level  3  testing. 

TTL7G.  Document  how  to  evaluate  the  test  results  for  accuracy 
and  completeness. 

According  to  clause  6.2.2,  Reference  9,  "Test  Specifications," 
one  needs  to  provide  guidelines  to  judge  test  results.  These 
guidelines  shall  be  used  to  decide  if  a  given  test  has  been 
passed  or,  in  the  case  of  failure,  shall  allow  the  testing 
laboratory  to  classify  errors  according  to  failure. 

These  are  complex  issues  requiring  consensus  among  the  interested 
parties,  which,  in  this  case,  include  the  CALS  user  and  supplier 
communities.  Accredited  Standards  Committee  X3H3,  and  ISO/IEC 
JTC1/SC24.  Meetings  with  Validation  and  Testing  Experts  will  be 
required  before  consensus  can  be  arrived  at. 
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Es-timated  Effort:  One  man-week  will  be  required  to  prepare  for 
level  1  and  level  2  testing  using  the  syntactic  checker  only.  An 
additional  two  to  four  man-weeks  will  be  required,  including 
participation  at  an  estimated  two  international  meetings  and  two 
or  three  national  meetings  over  a  12  month  period,  to  prepare  for 
using  a  semantic  checker  for  either  level  2  or  level  3  testing. 

TTLSG.  Participate  in  a  "field  test"  of  the  testing  method  for 
public  review  and  comment  during  a  "trial  use"  period. 

Clause  7.2.1,  Reference  9,  "Acceptance  of  the  Test  Suite," 
provides  for  two  rounds  of  testing— an  alpha  test  period  carried 
out  by  the  test  suite  developers  and  the  testing  laboratories  and 
a  beta  test  period  involving  the  test  laboratories  and  interested 
third  parties  (e.g.,  prospective  clients). 

TTLSGa.  Participate  in  an  alpha  "field  test"  of  the  testing 
method. 

During  the  alpha  test  period,  one  would  expect  to  be  spending  a 
considerable  amount  of  time  running  the  testing  programs  against 
as  large  a  variety  of  CGMs  as  one  could  get  one's  hands  on. 

Estimated  Effort:  One  man-week  for  the  syntactic  checker  used  in 
level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  one 
man-week  for  the  semantic  checker  proposed  for  level  2  or  level  3 
testing  (see  task  TTL3Gc) . 

•TTLSGb.  Participate  in  a  beta  "field  test"  of  the  testing 
method . 

During  the  beta  test  period,  one  would  expect  to  be  answering  a 
lot  of  questions  regarding  installation  and  procedures  and  also 
helping  prospective  clients  to  debug  their  implementations. 

Estimated  Effort:  Six  man-weeks  for  the  syntactic  checker  used 
in  level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  12 
man-weeks  for  the  semantic  checker  proposed  for  level  2  or  level 
3  testing  (see  task  TTL3Gc) . 

TTL9G.  Refine  the  test  method  as  a  result  of  the  "trial  use" 
period. 

TTL9Ga.  Collaborate  with  the  Certification  Body  and/or 
Accreditation  Body  to  arrive  at  consensus  on  what  changes  need  to 
be  made  after  the  alpha  test  phase. 

Estimated  Effort:  1.5  man-weeks  for  the  syntactic  checker  used 
in  level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  1.5 
man-weeks  for  the  semantic  checker  proposed  for  level  2  or  level 
3  testing  (see  task  TTL3Gc) . 
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TTL9Gb.  Implement  the  changes  resulting  from  the  alpha  test 
phase . 

Estimated  Effort:  2  man-weeks  for  the  syntactic  checker  used  in 
level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  2 
man-weeks  for  the  semantic  checker  proposed  for  level  2  or  level 
3  testing  (see  task  TTL3Gc) . 

TTL9GC.  Collaborate  with  the  Certification  Body  and/or 
Accreditation  Body  to  arrive  at  consensus  on  what  changes  need  to 
be  made  after  the  beta  test  phase. 

Estimated  Effort:  0.5  man-weeks  for  the  syntactic  checker  used 
in  level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  0.5 
man-weeks  for  the  semantic  checker  proposed  for  level  2  or  level 
3  testing  (see  task  TTL3Gc) . 

TTL9Gd.  Implement  the  cheuiges  resulting  from  the  beta  test 
phase. 

Estimated  Effort:  1.5  man-weeks  for  the  syntactic  checker  used 
in  level  1  and  2  testing  (see  tasks  TTL3Ga  and  TTL3Gb)  and  1.5 
man-weeks  for  the  semantic  checker  proposed  for  level  2  or  level 
3  testing  (see  task  TTL3Gc) . 

TTLIOG.  Develop,  negotiate,  amd  approve  appropriate  legal 
documents  and  procedures  that  protect  both  the  rights  of  the 
Government  and  the  test  method  owner  in  accordance  with  the 
provisions  of  Reference  8. 

In  particular,  license  agreements  with  the  Government,  the 
Certification  Body,  other  Testing  Laboratories,  and  the  clients 
need  to  be  drafted  and  approved  for  use. 

According  to  clause  7.4,  Reference  9,  "Issue  of  Licenses,"  two 
types  of  license  shall  be  required: 

-  a  license  for  clients  to  use  the  test  suite. 

-  a  license  for  testing  laboratories  to  enable  them  to 
use  the  test  suite  and  test  procedures  within  a  third 
party  test  service. 

The  procedures  allow  for  the  charging  of  a  fair  and  reasonable 
license  fee. 

Estimated  Effort:  For  level  1  and  level  2  testing  using  the 

syntactic  checker,  0.5  man-weeks  and  one  meeting  to  arrive  at  an 
"agreement  in  principle."  An  additional  0.5  man-weeks  of  a 
lawyer's  time  to  draft  and  agree  upon  the  exact  language  of  the 
license.  For  level  2  and  level  3  testing  using  the  semantic 
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checker,  an  additional  0.5  man-weeks  to  arrive  at  an  "agreement 
in  principle." 

TTLllG.  Develop  change  control  and  maintenance  procedures  for 
the  test  method. 

The  provisions  of  clause  6.1.3,  Reference  9,  "Maintenance  of  a 
Test  Suite,"  specify  that  the  test  suite  shall  be  subject  to  an 
agreed  review  procedure  with  a  publicly  known  timetable.  The 
procedures  shall  provide  formal  mechanisms  for  reporting  errors 
in  the  test  software,  withdrawing  invalid  tests,  and  logging 
changes  to  the  test  software. 

Clause  7.4,  "Maintenance  Requirements,"  specifies  that  change 
control  procedures  shall  be  required  to  enable  changes  to  be  made 
to  the  test  suite  in  a  controlled  manner.  The  change  control 
procedures  shall  encompass  the  test  suite,  the  test  procedures, 
and  the  test  report  format. 

Estimated  Effort:  Not  required  for  level  1  and  level  2  testing. 
1.5  man-weeks  for  the  syntactic  checker  and  1.5  man-weeks  for  one 
of  the  semantic  analyzers,  assuming  that  the  general  principles 
adopted  for  the  GKS  Testing  Service  are  accepted  for  CALS  MIL-D- 

28003  testing.  If  the  assumption  is  correct,  the  major  effort 

would  involve  adapting  the  GKS  procedures  (which  apply  to  an 

Application  Programmer  Interface  standard)  to  CGM  (which  is  a 
Data  Interchange  standard) . 

TCLIG.  Specify  and  document  the  steps  that  a  client  shall  follow 
in  order  to  have  a  product  tested  and  to  obtain  a  validation 
certificate. 

The  detailed  provisions  of  clause  7. 2. 2. 3,  Reference  9,  "Applying 
for  Testing,"  provide  for: 

the  client's  being  able  to  purchase  the  test  suite  for 
his  own  use; 

the  client's  submitting  a  scheduling  request  if  he 

wants  to  be  officially  certified; 

the  client's  reporting  the  results  of  a  "dry  run"  prior 
to  formal  testing; 

the  client's  seeking  resolution  of  any  queries  he  might 
have ;  and 

the  client's  scheduling  an  on-site  test. 

With  appropriate  thought  regarding  procedures,  it  might  be 
possible  to  abolish  the  need  for  on-site  testing  in  the  case  of 
testing  CGM  generators.  It  might  be  possible  for  the  client  to 
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submit  his  collection  of  CGMs — and  associated  documentation — for 
testing  at  the  laboratory  site.  This  will  be  possible  only  if  it- 
is  not  necessary  to  observe  the  generator-under-test  directly. 

Estimated  Effort:  This  task  is  applicable  only  to  level  3 
testing.  Two  man-weeks,  assuming  that  the  general  principles 
adopted  for  the  GKS  Testing  Service  are  accepted  for  CALS  MIL-D- 
28003  testing.  If  the  assumption  is  correct,  the  major  effort 
would  involve  adapting  the  GKS  procedures  (which  apply  to  an 
Application  Programmer  Interface  standard)  to  CGM  (which  is  a 
Data  Interchange  standard) . 

TCL2G.  Specify  and  document  the  statements  or  information 
provided  by  the  client  when  applying  for  conformance  testing 
leading  towards  a  validation  certificate. 

In  particular,  a  questionnaire  needs  to  be  developed  for  clients 
to  fill  out  and  submit  with  their  application  for  testing.  The 
questionnaire  will  require  specifics  about  the  environment  on 
which  their  software  runs  as  well  as  about  the  exact  CGM 
elements,  types,  and  precisions  produced  by  their  CGM  generator. 

From  this  information,  the  testing  laboratory  will  direct  the 
client  to  provide  a  certain  number  of  CGMs,  fitting  a  variety  of 
element  and  parameter  value  usage  profiles  driven  by  the 
docvimented  capabilities  of  the  generator-under-test.  The  success 
of  CGM  Generator  Testing  depends  upon  the  effective  completion  of 
this  task.  The  CGMs  provided  by  the  client  must  be 
representative  of  all  CGMs  producible  by  his  generator 
implementation,  because  the  client's  generator  is  certified  only 
by  validating  some  collection  of  the  CGMs  that  the  generator  has 
produced. 

Estimated  Effort:  This  task  is  applicable  only  to  level  3 
testing.  This  is  a  non-trivial  task  and  it  is  driven  by  the 
results  of  Tasks  TTL2Ga  and  TTL2Gb.  Three  man-weeks  should  be 
sufficient  if  the  Test  Requirements  document  is  thorough  and 
complete. 

5.3.3  Testing  for  Conforming  CGM  Interpreters 

All  the  tasks  described  in  this  section  relate  to  level  4  testing 
as  defined  above  in  section  5.1. 

TTLII.  Design  the  overall  test  method. 

For  the  interpreter,  the  test  method  will  include  the  preparation 
of  a  set  of  test  CGMs  (each  collection  is  known  as  a  CGM  Test 
Set)  with  associated  hard-copy  and  documentation.  The  results  of 
interpreting  the  CGMs  in  the  Test  Set  by  the  interpreter-under¬ 
test  will  be  compared  visually  with  the  reference  hard-copy  and 
conformance  will  be  established  according  to  documented  criteria. 
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Two  levels  of  testing  must  be  performed — one  for  CALS  Draft 
Quality  interpreters  and  one  for  CALS  Publication  Quality 
interpreters.  Each  Test  Set  should  be  targeted  at  verifying  the 
interpreter's  handling  of  a  certain  class  of  pictures  or  certain 
groups  of  elements.  Test  Sets  that  deliberately  include  out-of- 
range  parameter  values  and  illegal  CGM  syntax  should  also  be 
included. 

Estimated  Effort:  Three  man-weeks  and  one  meeting  with 

Certification  Body  officials  to  agree  upon  what  method  of  testing 
should  be  used  and  to  document  in  detail  the  test  method  design 
selected  for  interpreters. 

TTL2I.  Document  what  parts  of  the  standard  are,  in  fact,  to  be 
tested  by  the  test  suite.  Similarly,  document  those  areas  that 
are  not  to  be  tested  by  the  test  suite. 

A  Test  Requirements  Document  must  be  developed  from  two  sources: 
the  CGM  standard  itself  (ANSI/X3.122 — FIPS  PUB  128)  and  from  the 
CALS  AP  for  CGM  (MIL-D-28003) .  The  requirements  docvunent  will  be 
used: 

1.  to  specify  all  the  Test  Sets  that  must  be  developed  for 
inclusion  in  the  test  suite, 

2.  to  specify  what  allowable  differences  are  permitted 
among  realizations  of  the  CGMs  in  each  Test  Set  for 
both  Draft  Quality  and  Presentation  Quality 
interpreters ,  and 

3.  to  specify  the  information  about  the  client's  product 
needed  in  order  to  determine  which,  if  any,  of  the  CGMs 
in  any  of  the  Test  Sets  need  not  be  interpreted  by  the 
interpreter-under-test . 

In  each  area,  one  will  have  to  determine  whether  the  tests  should 
be  performed  in  any  particular  order  and  which  requirements  are 
more  important  for  testing  purposes.  This  substantial  task  can 
be  subdivided  into  smaller  tasks  to  simplify  the  job  of 
estimating  the  work  involved. 

TTL2Ia.  Dociunent  the  number  and  contents  of  the  CGM  Test  Sets 
required  to  verify  an  interpreter's  eibility  to  read  without  error 
CGMs  conforming  to  FIPS  PUB  128. 

This  sub-task  focusses  on  the  ability  of  the 
interpreter-under-test  to  handle  CGMs  conforming  to  the  FIPS 
correctly  from  the  syntactic  point  of  view. 

Estimated  Effort:  Three  man-weeks. 
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TTL2Ib.  Document  the  number  £md  contents  of  the  CGM  Test  Sets 
required  to  verify  an  interpreter's  eUbility  to  read  without  error 
CGHs  conforming  to  the  provisions  of  MIL-D-28003. 

This  sub-task  focusses  on  the  ability  of  the 
interpreter-under-test  to  also  handle  CGMs  conforming  to  the  CALS 
AP  correctly  from  the  syntactic  point  of  view. 

Estimated  Effort:  1.5  man-weeks,  because  the  results  documented 
in  Reference  14  can  be  used  as  a  starting  point,  although  they 
need  to  brought  up-to-date  to  reflect  the  final  draft  of 
MIL-D-28003.  This  estimate  assumes  the  completion  of  Task 
TTL2Ia. 

TTL2IC.  Document  the  modifications  needed  to  the  CGN  Test  Sets 
in  order  to  verify  an  interpreter's  ability  to  display  correctly- 
at  the  Draft  Quality  level-all  pictures  contained  in  CGMs 
conforming  to  MIL-D-28003. 

This  sub-task  focusses  on  the  ability  of  the 
interpreter-under-test  to  also  handle  CGMs  conforming  to  MIL-D- 
28003 — Draft  Quality  level — correctly  from  the  semantic  point  of 
view. 

Estimated  Effort;  1.5  man-weeks,  because  the  results  documented 
in  Reference  14  can  be  used  as  a  starting  point,  although  they 
need  to  brought  up-to-date  to  reflect  the  final  draft  of 
MIL-D-28003.  This  estimate  assumes  the  completion  of  Task 
TTL2Ib. 

TTL2Id.  Docmment  the  modifications  needed  to  the  CGM  Test  Sets 
in  order  to  verify  an  interpreter's  edaility  to  display  correctly- 
at  the  Publication  Quality  level-all  pictures  contained  in  CGMs 
conforming  to  MIL-D-28003. 

This  sub-task  focusses  on  the  ability  of  the 
interpreter-under-test  to  also  handle  CGMs  confomning  to  MIL-D- 
28003 — Publication  Quality  level — correctly  from  the  semantic 
point  of  view. 

Estimated  Effort:  1.5  man-weeks,  because  the  results  documented 
in  Reference  14  can  be  used  as  a  starting  point,  although  they 
need  to  brought  up-to-date  to  reflect  the  final  draft  of 
MIL-D-28003.  This  estimate  assumes  the  completion  of  Task 
TTL2IC. 

TTL3I.  Develop  the  test  suite. 

The  effort  for  each  subtask  assumes  that  an  interactive  utility 
tool  (see  Task  TTL4I  below)  has  been  developed  and  is  available 
for  use  by  test  suite  developers. 
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The  first  four  sub-tasks  described  in  the  following  use  the 
requirements  gathered  in  the  corresponding  sub-task  under  TTL2I 
above.  Each  of  these  sub-tasks  requires  the  completion  of  the 
predecessor  sub-task  prior  to  its  commencement. 

TTL3Ia.  Construct  and  assemble  the  CGM  Test  Sets  required  to 
verify  an  interpreter's  ability  to  read  without  erxor  CGHs 
conforming  to  FIPS  PUB  128. 

Estimated  Effort:  Six  man-weeks,  depending  upon  the  decisions 
made  about  the  thoroughness  of  the  test  method.  This  estimate 
assumes  that  100  CGMs  (at  2.5  man-hours  per  CGM)  will  be  needed. 

TTL3Ib.  Construct  and  assemble  the  CGM  Test  Sets  required  to 
verify  cin  interpreter's  ability  to  read  without  error  CGMs 
conforming  to  the  provisions  of  HIL-D-28003 . 

Estimated  Effort;  Three  man-weeks,  depending  upon  the  decisions 
made  about  the  thoroughness  of  the  test  method.  This  estimate 
assumes  that  50  more  CGMs  (at  2.5  man-hours  per  CGM)  will  be 
needed . 

TTIi3Ic.  Implement  the  modifications  needed  to  the  CGM  Test  Sets 
in  order  to  verify  an  interpreter's  ed>ility  to  display  correctly- 
at  the  Draft  Quality  level-all  pictures  contained  in  CGMs 
conforming  to  MIL-D-28003. 

Estimated  Effort:  Three  man-weeks,  depending  upon  the  decisions 
made  about  the  thoroughness  of  the  test  method.  This  estimate 
assumes  that  *50  more  CGMs  (at  2.5  man-hours  per  CGM)  will  be 
needed. 

TTL3Id.  Implement  the  modifications  needed  to  the  COI  Test  Sets 
in  order  to  verify  an  interpreter's  ability  to  display  correctly- 
at  the  Publication  Quality  level-all  pictures  contained  in  CGMs 
conforming  to  MIL-D-28003. 

Estimated  Effort;  Three  man-weeks,  depending  upon  the  decisions 
made  about  the  thoroughness  of  the  test  method.  This  estimate 
assumes  that  50  more  CGMs  (at  2.5  man-hours  per  CGM)  will  be 
needed. 

TTL3Ie.  Docinnent  the  allowable  differences  for  each  CGM  in  each 
of  the  CGM  Test  Sets  in  order  to  verify  an  interpreter's  ability 
to  display  correctly-at  the  Draft  Quality  level-all  pictures 
contained  in  CGMs  conforming  to  MIL-D-28003. 

Estimated  Effort;  1.5  man-hours  per  CGM.  This  task  is 
complicated  by  the  fact  that  the  differences  an  evaluator  might 
see  are  dependent  upon  the  basic  capabilities  of  the  interpreter, 
which  are  documented  by  the  client — see  Task  TCL2I. 
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TTL3If.  Dociiment  tlie  allowable  differences  for  each  CGH  in  each 
of  the  CGM  Test  Sets  in  order  to  verify  em  interpreter's  ed)illty 
to  display  correctly-at  the  Publication  Quality  level -all 
pictures  contained  in  CGMs  conforming  to  MIL-D-28003. 

Estimated  Effort:  An  additional  one  man-hour  per  CGM,  assuming 
the  completion  of  task  TTL3Ie. 

TTL4I.  Develop  any  required  support  tools. 

In  addition  to  the  tools  described  in  Tasks  TTL4Ia  and  TTL4Ib 
below,  the  testing  personnel  and  the  client  personnel  also  need  a 
reliable  utility  program  that  will  print  out,  in  a  convenient 
formatted  fashion,  the  contents  of  a  given  CGM  from  the  CGM  Test 
Set.  This  is  the  same  tool  needed  under  task  TTL4G,  and  the 
estimated  effort  for  its  development  will  not  be  repeated  here, 
because  it  is  assumed  that  TTL4G  will  have  been  completed  before 
work  on  Task  TTL4I  has  begun. 

TTIi4Ia.  Develop  a  tool  to  generate  specific  C(3Is  for  the  various 
CGM  Test  Sets. 

A  crucial  tool  is  an  interactive  program  that  permits  the  Test 
Set  Developer  to  build  any  CGM  needed  for  the  Test  Set.  NIST 
recommends  that  this  tool  be  based  on  a  reference  implementation 
of  the  CGM  that  can  accept  Clear  Tesct  Encoded  CGMs  and  produce 
the  equivalent  Binary  Encoded  CGM.  Extensions  to  permit  illegal 
and  ill-formed  CGMs  to  be  created  must  be  built  into  the  tool. 
Further  extensions  will  be  required  to  permit  elements  or  formats 
unique  to  the  Binary  Encoding  to  be  created  from  the  Clear  Text 
source.  During  the  work  on  Tasks  TTL2I  and  TTL3I,  further 
extensions  and  other  kinds  of  requirements  might  be  identified. 

Any  computer  tool  programs  written  to  support  the  Testing  Process 
shall  be  written  in  a  standard  high-level  programming  language. 
All  machine-dependent,  language-dependent,  and  operating-system- 
dependent  functionality  shall  be  isolated  into  we 11 -documented 
modules.  Variations  among  systems  shall  be  parameterized 
wherever  it  is  feasible  to  do  so. 

Programs  shall  be  written  to  be  small  enough  to  be  run  on 
Personal  Computer  class  machines. 

Estimated  Effort:  Twelve  man-weeks  if  one  already  has  a  baseline 
reference  implementation  to  build  upon  and  if  only  minimal 
ability  to  generate  erroneous  CGMs  is  provided.  The  principal 
effort  would  involve  improving  the  documentation  to  meet 
Government  standards,  implementing  the  extensions  required,  and 
testing  of  the  tool.  An  additional  8  man-weeks  will  be  required 
to  develop  more  sophisticated  capabilities  for  generating 
erroneous  CGMs. 
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This  estimated  effort  is  heavily  dependent  upon  the  initial 
parsing  and  reporting  capabilities  of  the  baseline  reference 
implementation,  if  one  can  be  found,  and  on  the  extent  of  the 
required  extensions. 

Without  a  baseline  implementation  to  build  upon,  this  effort 
could  easily  take  from  26  to  52  man-weeks. 

TTIi4Ib.  Develop  a  tool  to  enter  the  results  of  intezrpreting  each 
file  in  each  CGM  Test  Set  2tnd  generate  a  summary  test  report. 

The  display  or  hardcopy  of  dozens,  if  not  hundreds  or  thousands, 
of  CGMs  interpreted  by  the  implementation-under-test  will  need  to 
be  evaluated  by  a  human,  with  the  results  being  entered  into  a 
data  base  for  subsequent  summarization  and  reporting.  Some  kind 
of  access  to  a  DBMS  system,  via  "fill  in  the  form"  interactive 
screens  to  record  the  results  of  each  evaluation,  will  be 
required  to  manage  the  testing  process. 

Estimated  Effort:  8  to  16  man-weeks  if  one  can  find  a  good  DBMS 
system  to  build  the  particular  tool  upon.  The  principal  effort 
would  involve  designing  the  data  entry  screens,  designing  the 
content  of  the  data  base,  developing  the  documentation  to  meet 
Government  standards,  implementing  the  data  entry  panels  and 
report  generator  procedures  required,  and  testing  of  the  tool. 

The  estimated  effort  is  heavily  dependent  upon  the  availability 
of  a  good  DBMS  with  a  versatile  report  generator.  PC-based 
products  like  dBASE  III  and  Rbase  appear  to  be  good  candidates. 
They  could  be  placed  on  a  286  or  386  PC  laptop  computer  and  used 
by  testing  personnel  when  recording  their  evaluations.  The  raw 
data  from  each  evaluation  could  then  be  brought  back  to  the 
testing  laboratory  where  the  summary  report  would  be  generated. 

Without  an  off-the-shelf  DBMS  and  report  generator  to  build  upon, 
this  effort  could  take  from  26  to  52  man-weeks. 

TTL5I.  Design  the  test  report,  both  content  and  presentation 
layout. 

Reference  9,  clause  6.2.2,  suggests  that  the  test  report  shall 
provide  a  summary  of  tests  passed.  In  the  case  of  failure,  a 
detailed  description  of  errors  (parameter  values  and  other 
relevant  information) ,  helpful  information  for  the  implementor  to 
determine  errors,  and  a  reference  to  the  standard  shall  be 
provided.  Clause  7.3  further  requires  that  ISO  Guide  45  shall  be 
consulted  and  that  the  test  report  format,  as  a  minimum,  shall 
contain  the  following  information: 

description  of  product  under  test. 

-  description  of  the  test  environment. 


52 


-  a  svumnaxY  giving  numbers  of  test  cases  passed,  failed, 
withdrawn,  and  total  cases. 

-  full  details  for  each  test  case  which  failed. 

a  description  of  any  unexpected  results. 

A  unified  test  report  format  to  record  the  human  evaluation 
comparing  the  results  from  the  implementation-under-test  with  the 
reference  results  for  each  of  the  CGMs  in  each  of  the  CGM  Test 
Sets  will  have  to  be  designed. 

Estimated  Effort:  Two  man-weeks. 

TTL6I.  Develop  test  procedures » 

Extensive  documentation  for  both  testing  personnel  and  the  client 
is  required. 

TTL6Ia.  Develop,  document,  euid  test  procedures  for  installing 
the  utility  tools. 

Estimated  Effozrt:  Two  man-weeks. 

TTL6Ib.  Develop  and  document  an  operator  script  for  each  CGM  in 
the  Test  Set. 

Estimated  Effort:  One  man-hour  for  each  CGM.  This  estimate 

assumes  that  Tasks  TTL3Ie  and  TTL3If  have  been  completed. 
Testing  time  is  not  included  in  this  task.  It  is  assumed  that  it 
is  acceptable  to  overlap  testing  of  the  scripts  with  the  other 
testing  conducted  during  the  alpha  test  phase. 

TTL6IC.  Develop  emd  document  maintenemce  procedizres. 

Estimated  Effort:  Two  man-weeks.  It  is  assvuned  that  a  single 
procedure  can  be  developed  that  applies  to  all  CGMs  in  all  CGM 
Test  Sets. 

TTL6Id.  Develop  and  dociiment  procedures  for  on-site  modification 
of  the  tests. 

Estimated  Effort:  Two  man-weeks.  It  is  assumed  that  a  single 

procedure  can  be  developed  that  applies  to  all  CGMs  in  all  CGM 
Test  Sets. 

TTL6Ie.  Develop  and  document  procedures  regarding  the  retention 
of  hard  copy,  the  keeping  of  journals,  and  the  verification  that 
the  generator-under-test  represents  the  product  for  which  a 
certification  is  being  requested. 
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Es'tima'ted  Effort:  Two  man-weeks.  There  are  a  lot  of  details  to 
attend  to. 

TTL6If.  Develop  checklists  of  materials  to  take  for  on-site 
testing  and  checklists  of  materials  to  save  after  testing  is 
completed. 

Estimated  Effort:  One  man-week. 

TTL7I.  Docinnent  how  to  evaluate  the  test  results  for  accuracy 
auid  completeness. 

According  to  clause  6.2.2,  Reference  9,  "Test  Specifications," 
one  needs  to  provide  guidelines  to  judge  test  results.  These 
guidelines  shall  be  used  to  decide  if  a  given  test  has  been 
passed  or,  in  the  case  of  failure,  shall  allow  the  testing 
laboratory  to  classify  errors  according  to  failure. 

The  bulk  of  this  effort  is  already  included  in  Task  TTL6I  above. 
However  developing  general  guidelines  and  principles  from  which 
Task  TTL6I  would  derive  its  specific  instructions  is  a  complex 
matter  requiring  consensus  among  the  interested  parties,  which, 
in  this  case,  include  the  CALS  user  and  supplier  communities, 
Accredited  Standards  Committee  X3H3,  and  ISO/IEC  JTC1/SC24. 
Meetings  with  Validation  and  Testing  Experts  will  be  required 
before  consensus  can  be  arrived  at. 

Estimated  Effort:  Three  to  six  man-weeks  will  be  required, 
including  participation  at  an  estimated  two  international 
meetings  and  two  or  three  national  meetings  over  a  12  month 
period. 

TTL8I.  Participate  in  a  "field  test"  of  the  testing  method  for 
public  review  2md  comment  during  a  "trial  use"  period. 

Clause  7.2.1,  Reference  9,  "Acceptance  of  the  Test  Suite," 
provides  for  two  rounds  of  testing — an  alpha  test  period  carried 
out  by  the  test  suite  developers  and  the  testing  laboratories  and 
a  beta  test  period  involving  the  test  laboratories  and  interested 
third  parties  (e.g. ,  prospective  clients) . 

TTLSIa.  Participate  in  an  alpha  "field  test"  of  the  testing 
method. 

During  the  alpha  test  period,  one  would  expect  to  be  spending  all 
one's  time  testing  the  CGMs  in  all  the  CGM  Test  Sets  and  the 
associated  the  operator  scripts  for  each  CGM. 

Estimated  Effort:  One  man-hour  per  CGM  plus  two  man-weeks  for 
testing  the  procedures  and  the  reporting  program. 
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TTLSIb,  Participate  in  a  beta  "field  test"  of  the  testing 
method. 

During  the  beta  test  period,  one  would  expect  to  be  answering  a 
lot  of  questions  regarding  procedures  and  also  helping 
prospective  clients  to  debug  their  implementations. 

Estimated  Effort:  One  person  full  time  over  the  duration  of  the 
beta  testing  period,  say  12  man-weeks. 

TTL9I.  Refine  the  test  method  as  a  result  of  the  "trial  use" 
period. 

TTL9Ia.  Collaborate  with  the  Certification  Body  and/or 
Accreditation  Body  to  arrive  at  consensus  on  what  changes  need  to 
be  made  after  the  alpha  test  phase. 

Estimated  Effort;  Three  man-weeks  and  two  meetings. 

TTL9Ib.  Implement  the  changes  resulting  from  the  alpha  test 

phase . 

Estimated  Effort:  1  man-hour  per  changed  CGM  and  three 

additional  man-weeks  for  revising  the  procedures,  scripts, 
reporting  program,  and  instructions. 

TTL9IC.  Collaborate  with  the  Certification  Body  and/or 
Accreditation  Body  to  arrive  at  consensus  on  what  changes  need  to 
be  made  after  the  beta  test  phase. 

Estimated  Effort:  Two  man-weeks  and  one  meeting. 

TTL9Id.  Implement  the  changes  resulting  from  the  beta  test 

phase. 

Estimated  Effort:  1  man-hour  per  changed  CGM  and  two  additional 
man-weeks  for  revising  the  procedures,  scripts,  reporting 
program,  and  instructions. 

TTLIOI.  Develop,  negotiate,  and  approve  appropriate  legal 
documents  and  procedures  that  protect  both  the  rights  of  the 
Government  and  the  test  method  owner  in  accordance  with  the 
provisions  of  Reference  8. 

In  particular,  license  agreements  with  the  Government,  the 
Certification  Body,  other  Testing  Laboratories,  and  the  clients 
need  to  be  drafted  and  approved  for  use. 

According  to  clause  7.4,  Reference  9,  "Issue  of  Licenses,"  two 
types  of  license  shall  be  required: 

a  license  for  clients  to  use  the  test  suite. 
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a  license  for  testing  laboratories  to  enable  them  to 
use  the  test  suite  and  test  procedures  within  a  third 
party  test  service. 

The  procedures  allow  for  the  charging  of  a  fair  and  reasonable 
license  fee. 

Each  type  of  license  will  be  required  for  each  program  comprising 
the  generator  test  suite. 

Estimated  Effort:  One  man-week  and  one  meeting  to  arrive  at  an 
"agreement  in  principle"  regarding  rights  to  the  utility  tools 
and  to  the  CGMs  contained  in  the  various  CGM  Test  Sets.  An 
additional  man-week  of  a  lawyer's  time  and  one  additional 
meeting,  including  the  lawyer,  to  draft  and  agree  upon  the  exact 
language  of  the  license. 

TTLllI.  Develop  change  control  and  maintenance  procedures  for 
the  test  method. 

The  provisions  of  clause  6.1.3,  Reference  9,  "Maintenance  of  a 
Test  Suite,"  specify  that  the  test  suite  shall  be  subject  to  an 
agreed  review  procedure  with  a  pxablicly  known  timetable.  The 
procedures  shall  provide  formal  mechanisms  for  reporting  errors 
in  the  test  software,  withdrawing  invalid  tests,  and  logging 
changes  to  the  test  software. 

Clause  7.4,  "Maintenance  Requirements,"  specifies  that  change 
control  procedures  shall  be  required  to  enable  changes  to  be  made 
to  the  test  suite  in  a  controlled  manner.  The  change  control 
procedures  shall  encompass  the  test  suite,  the  test  procedures, 
and  the  test  report  format. 

Estimated  Effort:  Three  man-weeks,  assuming  that  the  general 
principles  adopted  for  the  GKS  Testing  Service  are  accepted  for 
CGM-D-28003  testing.  If  the  assumption  is  correct,  the  major 
effort  would  involve  adapting  the  GKS  procedures  (which  apply  to 
an  Application  Programmer  Interface  standard  and  to  source  code 
of  computer  programs)  to  CGM  (which  is  a  Data  Interchange 
standard  and  represents  a  file  format  and  content) . 

TCLII.  Specify  and  document  the  steps  that  a  client  shall  follow 
in  order  to  have  a  product  tested  and  to  obtain  a  validation 
certificate. 

The  detailed  provisions  of  clause  7. 2. 2. 3,  Reference  9,  "Applying 
for  Testing,"  provide  for: 

the  client's  being  able  to  purchase  the  test  suite  for 
his  own  use; 
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-  the  client's  submitting  a  scheduling  request  if  he 
wants  to  be  officially  certified; 

the  client's  reporting  the  results  of  a  "dry  run"  prior 
to  formal  testing; 

the  client's  seeking  resolution  of  any  queries  he  might 
have ;  and 

the  client's  scheduling  an  on-site  test. 

With  appropriate  thought  regarding  procedures,  it  might  be 
possible  to  minimize  the  length  of  time  required  for  on-site 
testing  in  the  case  of  testing  CGM  interpreters.  If  the  client 
interpreter  can  produce  hardcopy,  it  should  be  possible  for 
testing  personnel  to  oversee  interpretation  at  the  client  site 
and  then  bring  back  the  hardcopy  for  evaluation  at  the  laboratory 
site.  This  would  permit  less  skilled  and/or  less  experienced 
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accepted  for  CGM-D-28003  testing.  If  the  assumption  is  correct, 
the  major  effort  would  involve  adapting  the  GKS  procedures  (which 
apply  to  an  Application  Programmer  Interface  standard)  to  CGM 
(which  is  a  Data  Interchange  standard) . 

TCL2I .  Specify  and  dociiment  the  statements  or  information 
provided  by  the  client  when  applying  for  conformance  testing 
leading  towards  a  validation  certificate. 

In  particular,  a  questionnaire  needs  to  be  developed  for  clients 
to  fill  out  and  submit  with  their  application  for  testing.  The 
questionnaire  will  require  specifics  about  the  environment  on 
which  their  software  runs  as  well  as  about  the  exact  CGM 
elements,  types,  and  precisions  handled  by  their  implementation. 

Some  of  the  information  provided  by  the  client  will  influence  the 
criteria  used  to  determine  whether  an  interpreter-under-test 
meets  the  CALS  AP  for  Draft  Quality  CGM  Interpreters. 

Estimated  Effort;  This  is  a  non-trivial  task  and  it  is  driven  by 
the  results  of  Tasks  TTL2Ia  and  TTL2Ib.  Three  man-weeks  should 
be  sufficient  if  the  Test  Requirements  document  is  thorough  and 
complete. 
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IV.  SUMMARY  AND  CONCLUSIONS 


This  section  summarizes  the  major  svibsections  of  section  III  as 
follows: 


o 

Section 

1 

below 

siimmarizes 

section 

III, 

subsection 

3; 

o 

Section 

2 

below 

summarizes 

section 

III, 

subsection 

4 ; 

and 

o 

Section 

3 

below 

summarizes 

section 

III, 

subsection 

5. 

1.0  Summary  of  Commercial  Implementations 

The  100  metafiles  studied  are  broadly  representative  of  the  full 
range  of  uses  in  which  the  CGM  can  be  valuable.  Only  the 
following  CGM  elements  did  not  appear  in  any  of  the  CGMs  studied: 

VDC  REAL  PRECISION 
RESTRICTED  TEXT 
GENERALIZED  DRAWING  PRIMITIVE 
CIRCULAR  ARC  3  POINT 
CIRCULAR  ARC  3  POINT  CLOSE 

Line,  Marker,  Text,  Fill,  and  Edge  BUNDLE  INDEX 
ALTERNATE  CHARACTER  SET  INDEX 
EDGE  WIDTH 
MESSAGE 

These  are  CGM  elements  that  represent  functionality  rarely  found 
in  today's  graphics  applications. 

However,  several  other  elements  are 
metafiles  surveyed.  These  include: 

METAFILE  DEFAULTS  REPLACEMENT 
FONT  LIST 

CHARACTER  SET  LIST 
CHARACTER  CODING  ANNOUNCER 
AUXILIARY  COLOR 
TRANSPARENCY 
DISJOINT  POLYLINE 
APPEND  TEXT 
POLYGON  SET 
CELL  ARRAY 
CIRCULAR  ARC  CENTER 

Some  companies  have  learned  the  value  of  these  elements  and  have 
incorporated  them  in  their  CGMs.  However,  all  worry  that  if  they 
use  these  less  well-known  elements,  there  will  be  no  products 
that  can  interpret  their  metafiles. 


used  infrequently  in  the 


CIRCULAR  ARC  CENTER  CLOSE 
ELLIPSE 

ELLIPTICAL  ARC 
ELLIPTICAL  ARC  CLOSE 
CHARACTER  SET  INDEX 
The  Edge  Attributes 
FILL  REFERENCE  POINT 
PATTERN  TABLE 
PATTERN  SIZE 
ASPECT  SOURCE  FLAGS 
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Only  six  companies  use  ESCAPE  elements  and  only  two — Lotus  and 
System  One  Software — use  APPLICATION  DATA  elements.  It  is  not 
known  if  the  information  contained  in  these  elements  is  vital  for 
the  proper  display  of  the  picture  represented  by  the  CGM.  In  at 
least  one  case — Lotus,  the  information  is  not  required  for 
displaying  purposes;  rather,  the  information  would  be  used  when 
reading  in  the  metafile  for  further  manipulation  by  an  editing 
program. 

The  small  number  of  companies  using  METAFILE  DEFAULTS  REPLACEMENT 
and  FONT  LIST  indicates  that  a  substantial  education  process  is 
required  in  order  to  improve  interoperability  of  metafiles 
containing  text.  A  lesser  effort  will  be  required  to  educate  the 
five  companies  that  don't  place  a  COLOR  TABLE  element  in  the  CGM 
even  when  they  use  indexed  color  selection  mode. 

In  this  task,  the  variability  of  commercial  CGM  generator 
implementations  was  studied  and  the  degree  of  conformance  to  the 
CALS  Application  Profile  for  CGM  (MIL-D-28003)  was  assessed.  The 
conclusions  are  that: 

o  Most  companies  should  be  able  to  upgrade  their  CGM 
generator  products  to  conform  to  MIL-D-28003  without 
excessive  or  burdensome  additional  investment. 

o  Upgrading  of  interpreters  to  meet  the  CALS  Draft  Level 
of  conformance  should  be  straightforward  but  not 
trivial;  upgrading  to  the  Publication  Level  of 
conformance  will  be  more  costly  and  time-consxming. 

o  Any  discrepancies  between  the  CGMs  produced  by  products 
seeking  to  conform  to  MIL-D-28003  will  be  the  result  of 
misunderstandings  and  not  deliberate  decisions  due  to 
difficulty  of  implementation. 

Consequently,  NIST  recommends  that; 

1.  The  testing  of  CGM  generators  to  MIL-D-28003  be  given 
priority  over  the  testing  of  CGM  interpreters. 

2.  CALS  support  and  encourage  vendor  demonstrations  like 
CALS  EXPO  and  NCGA's  Integrate '89  to  facilitate  vendor 
education  and  accelerate  vendor  compliance  with 
MIL-D-28003. 

In  section  VI,  seven  specific  recommendations  are  provided 
concerning  the  certification  of  CGM  implementations. 


2.0  Conformance  Checklist  Summazry — Commercial  .vs.  MIL-D-28003 
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A  svunmary  of  how  well  the  implementations  studied  meet  the 
requirements  of  MIL-D-28003  is  presented  in  tabular  form  in  the 
following  pages. 

Each  of  the  CALS  AP  requirements  is  presented  as  a  row  and  each 
of  the  CGM  generator  implementations  is  presented  as  a  column. 
In  the  cell  at  the  intersection  of  a  row  and  column  is  an 
indicator  of  conformance  to  the  CALS  AP.  The  symbols  used  are  as 
follows: 


Y  Means  the  generator  meets  the  CALS  requirement. 

N  Means  the  generator  does  not  meet  the  CALS  requirement. 
Means  the  generator  does  not  use  the  CGM  element  on 
which  the  requirement  falls. 

?  Means  that  not  enough  information  was  available  for  the 
implementation  in  question. 

*  When  attached  to  a  y  or  n  means  that  the  implementation 
complies  with  the  spirit  of  the  requirement  but 
deviates  in  some  small  way. 
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.2. 


4.2.1.2.al 


4.2.1.2.a2 


3 

2 

• 

2 

3 

2 

• 

3 

AUT 

SOP 

No-ops  <  32767 


MD  contains  product 
or  company  name 


N  N 


MD  contains  string 

''MIL-D-28003/BASIC-1"  N*  N  N  N  N*  N 


wHummm 


Integer  Precision  =  16 


Real  Precision=(l, 16, 16) 
or  (0,9,23) 


Index  Precision  *  16 


Color  Precision=8  or  16 


Color  Index  Prec.=8orl6 


Font  List  <=  ' 


Char.  Set  List  present  &  N  N  N  N  N  N 

contains  (0, 4/2) (1, 4/1)  _  _  -  -  - 


CCA  =  0  or  1 


If  metric,  SCALING  MODE 
parameter  is  (0,9,23) 


VDC  Int.  Prec.=  16  or  32  Y 


VDC  Real  Prec.=(l,16,16) 
or  (0,9,23) 


No  GDPs  allowed 


l<=Line  Bundle  Index<=5 


1  <=  Line  Type  <=5  or 

-11301  <=  L.T.  <=  -11308  N  N  N 


61 


.2. 


.2 


4. 2.1. 6. m 


4 . 2 . 1. 6.n 


.2. 


4. 2. 1.8 


I 


.3. 


.3.2 


.3.3 


.3. 


3 

• 

2 

• 

2 

3 

• 

2 

3 

AUT 

SOP 

l<=Marker  Bun.Index<=5 


1  <=  Marker  Type  <=  5 


l<=Text  Bun.  Index  <-2 


l<=Text  Font  Index  <=4 


l<=Char.  Set  Index  <-2 


l<=Alt. Char. Set  Ind<=2 


l<=Fill  Bun.  Index  <*5 


1<=  Hatch  Index  <=6  or 
-11401<=  H. I. <=-11418 


l<=Edge  Bun. Index  <»5 


1  <=  Edge  Type  <=5 


l<=Pattern  Tab.lnd.<=8 
Each  Pattern  wi  16x16 


0<=ColorTableInd. <=255 


Only  ESCAPE  Els:-301&2 


Only  MESSAGE  w/  Flag  = 
"no  action  required" 


Uses  B-inary  Encoding 


80 -Octet  Records 


N 


N  N 


Def.  text  prec  STROKE  N  N  N  N 


Don't  use  color  indices 
unless  set/follow  CALS 
default  table 


3 

• 

2 

5 

3 

2 

6 

GEN 

GPT 

B 

H 

H 

H 

H 

H 

N 

N 

N  N 


N 
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ATC  AUT  SOP  CAI  GEN  GPT 


.3.5 


4. 3. 8. a 


4.3.8.b 


4.3 .8. C 


4.3.8.d 


4.3.8.e 


4.3.8.f 


Only  Hershey  Font  Names 
in  Font  List  Element 


MDR  shall  not  be  part'd 


Cell  arrays<=l, 048, 576 


Pattern  Tables  <*2048 


Color  Tables  <=  256 
entries 


Point  arrays  <=  1024 
pairs 


Data  records  <=  32767 


Strings  <*  256 


IBI 

iBi 


a 
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4.2.1.2.al 


4.2.1. 2. a2 


GSS  HPS  IBM  LOT  MOD  MDT 


Char.  Set  List  present  &  N  N  N  N 
contains  (0,4/2) (1,4/1)  <  '  '  ' 


CCA  =  0  or  1 


If  metric,  SCALING  MODE 
parameter  is  (0,9,23) 


VDC  Int.  Prec.=  16  or  32 


VDC  Real  Prec.=(l,16,16) 
or  (0,9,23) 


No  GDPs  allowed 


l<=Line  Bundle  Index<=5 


1  <=  Line  Type  <=5  or 

-11301  <=  L.T.  <=  -11308  N  N  N  N 


No-ops  <  32767 


MD  contains  product 
or  company  name 


MD  contains  string 

••MIL-D-28003/BASIC-1"  N  N*  N  N  N*  N 


Integer  Precision  =  16 


Real  Precision=(l, 16, 16) 
or  (0,9,23) 


Index  Precision  =  16 


Color  Precision=8  or  16 


Color  Index  Prec.=8orl6 


I 

I 

I 

I 

I 

I 


.2. 


.2. 


•  2  • 


.2. 


.2  . 


.2. 


2.1.6. 


2. 


.2. 


2. 


4 . 2 . 1. 6.in 


4 . 2 . 1. 6.n 


.2. 


4. 2. 1.8 


I 


.3. 


.3.2 


.3.3 


.3. 


7 

8 

9 

10 

GSS 

HPS 

IBM 

LOT 

n 

D 

B 

B 

N 

N 

N 

N 

n 

B 

B 

B 

N 

N 

N 

N 

D 

B 

B 

B 

- 

- 

- 

- 

a 

B 

B 

B 

3 

2 

11 

3 

2 

12 

MCD 

MDT 

N  N 


N  N 


H 


l<=Marker  Bun.Index<=5 


1  <=  Marker  Type  <=  5 


l<=Text  Bun.  Index  <=2 


l<=Text  Font  Index  <=4 


l<=Char.  Set  Index  <=2 


l<=Alt. Char. Set  Ind<=2 


l<=Fill  Bun.  Index  <=5 


1<=  Hatch  Index  <=*6  or 
-11401<=  H. I. <=-11418 


l<=Edge  Bun. Index  <=5 


1  <=  Edge  Type  <=5 


l<=Pattem  Tab.Ind.<=8 
Each  Pattern  wi  16x16 


0<=ColorTableInd. <=255 


Only  ESCAPE  Els;-301&2  N  N  N  N 


Only  MESSAGE  w/  Flag  = 
"no  action  required" 


Uses  Binary  Encoding 


80-0ctet  Records 


Def.  text  prec  STROKE  N 


Don't  use  color  indices 
unless  set/ follow  CALS  N 
default  table 


N 

N 

N 

N 

N 

N 
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3 

• 

2 

• 

7 

3 

• 

2 

• 

8 

3 

• 

2 

• 

9 

3 

• 

2 

• 

10 

3 

• 

2 

• 

11 

3 

• 

2 

12 

GSS 

HPS 

IBM 

LOT 

MCD 

MDT 

mm 

Only  Hershey  Font  Names 
in  Font  List  Element 

■ 

■ 

B 

- 

Y* 

Y* 

4.3.6 

MDR  shall  not  be  part'd 

a 

D 

B 

- 

B 

B 

4. 3. 8. a 

Cell  arrays<=l, 048, 576 

D 

B 

B 

- 

B 

B 

4.3.8.b 

Pattern  Tables  <=2048 

- 

- 

- 

- 

- 

- 

4.3.8.C 

Color  Tables  <=  256 
entries 

H 

■ 

B 

- 

B 

B 

• 

00 

• 

n 

. 

Point  arrays  <=  1024 
pairs 

■ 

B 

B 

7 

B 

B 

0) 

• 

00 

• 

• 

Data  records  <=  32767 

D 

a 

B 

B 

B 

B 

4.3.8.f 

Strings  <=  256 

H 

D 

B 

B 

B 

B 

I 
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.2. 


4.2.1.2.al 


4.2.1.2.a2 


2. 1.4. a 


3 

• 

2 

• 

13 

3 

a 

2 

• 

14 

3 

• 

2 

• 

15 

3 

2 

• 

16 

3 

2 

• 

17 

NOV 

PAN 

OPT 

IVI 

PRM 

No-ops  <  32767 


MD  contains  product 
or  company  name 


MD  contains  string 

••MIL-D-28003/BASIC-1''  N  N  N*  N*  N  N 


Integer  Precision  =  16 


Real  Precision® (1, 16, 16) 
or  (0,9,23) 


Index  Precision  =  16 


Color  Precision=8  or  16  Y* 


Color  Index  Prec.®8orl6  Y* 


Font  List  <=  - 


Char.  Set  List  present  &  N  N  N  N  N  N 
contains  (0,4/2) (1,4/1) 


CCA  =  0  or  1 


If  metric,  SCALING  MODE 
parameter  is  (0,9,23) 


VDC  Int.  Prec.®  16  or  32 


VDC  Real  Prec.=(l, 16, 16) 
or  (0,9,23) 


No  GDPs  allowed 


l<=Line  Bundle  Index<®5  N 


1  <=  Line  Type  <=5  or 
-11301  <=  L.T.  <=  -11308 


N  N 
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4c2.1.6.f 


4. 2.1. 6. h 


4. 2.1. 6. j 


4. 2.1. 6. k 


4. 2.1. 6. m 


4. 2.1. 6. n 


l<=Marker  Bun.Index<=5 


1  <=  Marker  Type  <=  5 


l<=Text  Bun.  Index  <=2 


l<=Text  Font  Index  <=4 


l<=Char.  Set  Index  <=2 


l<=Alt. Char. Set  Ind<=2 


l<=Fill  Bun.  Index  <=5 


1<=  Hatch  Index  <=6  or 
-11401<=  H. I. <=-11418 


l<=Edge  Bun. Index  <=5 


1  <=  Edge  Type  <=5 


l<=Pattern  Tab.Ind.<=8 
Each  Pattern  wi  16x16 


0<=ColorTableInd. <=255 


Only  ESCAPE  Els:-301&2 


Only  MESSAGE  w/  Flag  = 
"no  action  required” 


Uses  Binary  Encoding 


80 -Octet  Records 


Def.  text  prec  STROKE 


Don't  use  color  indices 
unless  set/ follow  CALS 
default  table 


NOV  PAN  OPT  PVI  PRM  SPB 


N  N 


N  N 


N  N 
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3 


3 


3 


3 


3 


• 

2 

2 

2 

2 

2 

2 

13 

14 

• 

15 

• 

16 

17 

18 

NOV 

PAN 

OPT 

PVI 

PRM 

SPB 

Only  Hershey  Font  Names 
in  Font  List  Element 

Y* 

■ 

■ 

B 

B 

B 

4.3.6 

MDR  shall  not  be  part'd 

- 

- 

- 

- 

- 

- 

4. 3. 8. a 

Cell  arrays<=l, 048, 576 

D 

n 

D 

D 

D 

- 

4.3.8.b 

Pattern  Tables  <=2048 

D 

D 

N 

H 

N 

- 

4.3.8.C 

Color  Tables  <=  256 
entries 

H 

■ 

B 

H 

B 

y 

4.3.8.d 

Point  arrays  <=  1024 
pairs 

■ 

■ 

B 

B 

B 

B 

4.3.8.e 

Data  records  <=  32767 

B 

B 

B 

D 

B 

a 

4.3.8.f 

Strings  <=  256 

B 

B 

B 

D 

B 

a 

.2. 


4. 2.1. 6. b 


1  <=  Line  Type  <=5  or 
-11301  <=  L.T.  <=  -11308  N 
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.2 


.2. 


4 . 2 . 1. 6.in 


4 . 2 . 1 . 6  .  n 


.2. 


4. 2. 1.8 


I 

E 

E 

I 


.  3  . 


.3.2 


.3.3 


.3. 


19  20  21  22  23 


SUN  SOS  TKN  WAS  ZEN 


l<=Marker  Bun.Index<=5 


1  <=  Marker  Type  <=  5 


l<=Text  Bun.  Index  <=2 


l<=Text  Font  Index  <=4 


l<=Char.  Set  Index  <=2 


l<=Alt. Char. Set  Ind<=2 


l<=Fill  Bun.  Index  <=5 


1<=  Hatch  Index  <-6  or 
-11401<=  H. I. <=-11418 


l<=Edge  Bun. Index  <=5 


1  <=  Edge  Type  <=5 


l<=Pattern  Tab.Ind.<=8 
Each  Pattern  wi  16x16 


0<=ColorTableInd. <=255 


Only  ESCAPE  Els:-301&2 


Only  MESSAGE  w/  Flag  = 
"no  action  required" 


Uses  Binary  Encoding 


80 -Octet  Records 


Def.  text  prec  STROKE 


Don't  use  color  indices 
unless  set/ follow  CALS 
default  table 


g 


N  N  N 


N  N 


N 

N 

N 

N 

N 

N 
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3.5 


Only  Hershey  Font  Names 
in  Font  List  Element 


4.3.6 

MDR  shall  not  be  part'd 

4. 3. 8. a 

Cell  arrays<=l,048^ 576 

4.3.8.b 

Pattern  Tables  <=2048 

4.3.8.C 

Color  Tables  <=  256 
entries 

4.3.8.d 

Point  arrays  <=  1024 
pairs 

4.3.8.e 

Data  records  <=  32767 

4.3.8.f 

Strings  <=  256 

3.0  Siimmary  of  Conformance  Testing  Tasks 
3 . 1  Development  Phases 


There  is  a  logical  progression  that  one  can  follow  for  the 
introduction  of  CGM  testing  services.  This  approach  is 
cost-effective  and  is  outlined  in  the  following: 

Phase  1  Develop,  license,  and  make  availauble  for  purchase  a  CGM 
syntax  analyzer  (as  described  in  task  TTL3Ga)  that 
checks  instances  of  CGMs  for  conformance  to  FIPS  PUB 
128  along  with  the  utility  program  that  prints  out  the 
contents  of  a  CGM-under-test  (as  described  in  task 
TTL4G) . 

This  Test  Suite  would  be  used  by  suppliers  to  verify 
that  the  CGMs  they  produce  indeed  conform  to  the  FIPS 
and  by  users  to  verify  that  the  CGMs  they  are  receiving 
conform  to  the  FIPS.  No  formal  testing  service  would 
be  established  at  this  time. 

Phase  2  Develop,  license,  and  make  available  for  purchase  an 
augmentation  to  the  CGM  syntax  analyzer  (as  described 
in  task  TTL3Gb)  that  checks  instances  of  CGMs  for 
conformance  to  MIL-D-28003. 

This  augmented  Test  Suite  would  be  used  by  CALS 
suppliers  to  verify  that  the  CGMs  they  produce  indeed 
conform  to  MIL-D-28003  and  by  CALS  users  to  verify  that 
the  CGMs  they  are  receiving  conform  to  MIL-D-28003.  No 
formal  testing  service  would  be  established  at  this 
time. 


Phase  3  Develop,  license,  and  make  available  for  purchase  a  CGM 
graphical  interpreter  (as  described  in  task  TTL3Gc) 
that  can  display  any  CALS  basic  conforming  CGM  and  that 
meets  at  least  the  Draft  Quality  interpreter 
requirements  of  MIL-D-28003. 

The  resulting  augmented  Test  Suite  would  be  used  by 
suppliers  and  users  alike  to  assist  in  determining 
semantic  correctness  to  supplement  the  syntactic 
correctness  report  provided  by  Phase  2 .  Still ,  no 
formal  testing  service  would  be  established  at  this 
time. 

Phase  4  Establish  a  testing  service  to  validate  and  certify 
CALS  CGM  generators  for  syntactic  correctness. 

This  phase  involves  performing  the  requirements 
analysis  described  in  tasks  TTL2Gc  and  TTL2Gd  and  all 
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Phase  5 


Phase  6 


Phase  7 


Phase  8 


the  other  tasks  listed  in  sections  3  and  4  above  that 
relate  to  establishing  a  formal  testing  service  for  CGM 
generators . 

Augment  the  generator  testing  service  to  validate  and 
certify  CALS  CGM  generators  for  both  syntactic 
correctness  and  semantic  correctness. 

The  principal  additional  efforts  over  Phase  3  and  Phase 
4  involve:  (a)  documenting  the  procedures  and  criteria 
associated  with  the  human  inspection  process  implied  by 
checking  for  semantic  correctness;  and  (b)  upgrading 
the  reference  implementation  CGM  interpreter  used  in 
Phase  3  to  function  at  the  Pxiblication  Quality  level 
specified  in  MIL-D-28003. 

Establish  a  testing  service  to  validate  and  certify 
CALS  CGM  interpreters.  Interpreters  will  be  checked 
for  their  ability  to  read  CALS  conforming  basic  CGMs 
and  display  them  at  the  Draft  Quality  interpretation 
level.  Very  little  emphasis  will  be  placed  on  testing 
for  reaction  to  out-of-range  values  and  proper  handling 
of  non-conforming  CGMs. 

This  phase  involves  performing  most  of  the  tasks 
specified  in  section  4.3  above.  The  effort  is  based  on 
a  Test  Suite  consisting  of  200  CGMs. 

Augment  the  Phase  6  testing  service  for  CALS  CGM 
interpreters.  Interpreters  will  be  checked  for  their 
ability  to  read  CALS  conforming  basic  CGMs  and  display 
them  at  the  Publication  Quality  interpretation  level. 
As  with  Phase  6,  very  little  emphasis  will  be  placed  on 
testing  for  reaction  to  out-of-range  values  and  proper 
handling  of  non-conforming  CGMs. 

The  additional  work  involves  modifying  the  operator 
scripts  and  certification  and  validation  criteria  to 
reflect  the  requirements  of  Publication  Quality 
interpretation.  This  effort  assumes  that  an  additional 
50  CGMs  will  be  added  to  the  Test  Suite. 

Augment  the  Phase  6  or  Phase  7  testing  service  for  CALS 
CGM  interpreters.  Substantial  emphasis  will  be  placed 
on  the  interpreter's  response  to  out-of-range  values 
and  degenerate  primitives.  The  proper  handling  of 
non-conforming  CGMs  will  also  be  verified. 

The  additional  work  involves;  (a)  upgrading  the  CGM 
creation  tool  to  create  erroneous  CGMs;  (b)  creating 
lots  of  new  operator  scripts;  and  (c)  augmenting 
certification  and  validation  criteria  to  reflect  the 
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requirements  of  MIL-D-28003.  This  effort  assumes  that 
an  additional  200  CGMs  will  be  added  to  the  Test  Suite. 


3.2  Summary  Tables 

Table  3-1  lists  all  the  tasks  (along  with  the  Task  Identifier) 
associated  with  the  responsibilities  of  the  Certification  Body 
already  described  in  section  III,  subsection  5.2.2.  Table  3-2 
lists  all  the  tasks  (along  with  the  Task  Identifier)  associated 
with  the  operation  of  a  CGM  generator  testing  service  by  a 
Testing  Laboratory  and  the  two  tasks  associated  with  the 
responsibilities  of  the  Client.  These  tasks  have  been  detailed 
in  section  III,  subsection  5.3.2.  Table  3-3  lists  all  the  tasks 
(along  with  the  Task  Identifier)  associated  with  the  operation  oi: 
a  CGM  interpreter  testing  service  by  a  Testing  Laboratory  and  the 
two  tasks  associated  with  the  responsibilities  of  the  Client. 
These  tasks  have  been  detailed  in  section  III,  subsection  5.3.3. 

Table  3-4  summarizes  the  Certification  Body  man-day  estimates  for 
all  eight  phases.  Table  3-5  summarizes  the  man-day  estimates  for 
Phases  1  through  5,  related  to  successively  more  complete  CGM 
generator  testing,  while  Table  3-6  summarizes  the  man-day 
estimates  for  Phases  6  through  8,  related  to  successively  more 
complete  CGM  interpreter  testing. 

Generally  speaking,  the  tasks  listed  in  Tedale  3-4  represent  tasks 
that  would  have  to  be  performed  by  the  Certification  Body,  or 
delegated  to  some  neutral,  governmental  or  guasi-govemmental 
body  and  performed  by  in-house  personnel.  The  tasks  listed  in 
Tables  3-5  and  3-6  represent  tasks  that  would  be  expected  to  be 
contracted  out  to  a  third-party  supplier,  often  referred  to  as 
the  test  method  developer.  Once  the  developer  has  finished  his 
work  and  the  legal  terms  and  conditions  negotiated  for  use  ofthe 
finished  products,  the  results  of  the  tasks  would  be  made 
available  for  licensing  to  the  general  supplier  and  user 
community  and  would  be  utilized  by  Testing  Laboratory  personnel 
in  performance  of  their  duties  as  part  of  any  formal  Testing 
Service  established  by  the  Certification  Body. 
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Table  3-1.  Tasks  Associated  with  the  Certification  Body 


Task  ID 


Task  Description 


TCBl 

TCB2 

TCB3 

TCB4 

TCB5 

TCB6 

TCB7 

TCB8 

TCB9 

TCBIO 

TCBll 

TCB12 

TCB13 


Develop  overall  policies  and  procedures. 
Approve  the  design  of  the  test  method. 
Conduct  "alpha"  and  "beta"  field  tests. 
Approve  revisions  to  test  method  resulting 
field  tests. 

Approve  test  report  forms. 

Develop  validation  procedures. 

Determine  validation  criteria. 

Design  validation  certificate. 

Establish  Testing  Laboratory  (TL) 
accreditation  criteria. 

Conduct  initial  proficiency  testing  of  TL 
personnel . 

Verify  TL's  recordkeeping  system. 

Develop  appeal  procedures.  Establish 
control  board. 

License  testing  tools.  Establish  fees. 


from 
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Tcible  3-2.  Tasks  Associated  with  Testing  Laboratory  Operation 
and  Client  Responsibilities  with  re^jpect  to  CGM  Generator  Testing 


Task  ID 


Task  Description 


TTLIG 

TTL2G 

TTL2Ga 

TTL2Gb 

TTL2GC 

TTL2Gd 

TTL3G 

TTL3Ga 

TTL3Gb 

TTL3GC 

TTL4G 

TTL5G 

TTL6G 

TTL6Ga 

TTL6Gb 

TTL6GC 

TTL6Gd 

TTL6Ge 

TTL6Gf 

TTL7G 

TTL8G 

TTLSGa 

TTLSGb 

TTL9G 

TTL9Ga 

TTL9Gb 

TTL9GC 

TTL9Gd 

TTLIOG 

TTLllG 


Design  the  test  method. 

Develop  test  requirements  document: 

Document  requirements  for  conformance  to  FIPS  PUB 
128. 

Document  requirements  for  conformance  to 
MIL-D-28003. 

Document  range  of  test  CGMs  needed  for  FIPS 
conformance. 

Document  range  of  test  CGMs  needed  for  MIL-D-28003 
conformance. 

Develop  test  suite: 

Develop  FIPS  syntax  analyzer. 

Develop  MIL-D-28003  syntax  analyzer. 

Develop  reference  CGM  interpreter. 

Develop  utility  to  print  the  content  of  Binary  CGMs. 
Design  the  test  reports. 

Develop  test  procedures: 

For  test  programs  and  utility  tool. 

Operator  scripts  for  each  test. 

Maintenance  procedures. 

On-site  modifications. 

On-site  recordkeeping  requirements. 

Checklists  of  materials. 

Document  how  to  evaluate  test  results. 

Participate  in  field  tests: 

Alpha  field  test. 

Beta  field  test. 

Refine  test  method  as  result  of  field  tests: 

Design  changes  after  alpha  results  known. 

Implement  alpha  changes. 

Design  changes  after  beta  results  known. 

Implement  beta  changes. 

Negotiate  license  terms  and  conditions. 

Develop  change  control  procedures  for  the  test  method. 


TCLIG 

TCL2G 


Specify  steps  to  be  followed  by  client. 
Specify  information  needed  from  client. 
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Table  3-3.  Tasks  Associated  with  Testing  Ledaoratory  Operation 
and  Client  Responsibilities  with  respect  to  CGH  Interpreter 
Testing 

Task  ID  Task  Description 


TTLII  Design  the  test  method. 

TTL2I  Develop  test  requirements  docximent: 

TTL2Ia  Document  requirements  for  conformance  to  FIPS  PUB 

128. 


TTL2Ib 

Document  requirements 

for 

conformance  to 

TTL2IC 

MIL-D-28003. 

Document  requirements 

for 

Draft 

Quality 

TTL2Id 

interpretation . 

Document  requirements  for 

Publication 

Quality 

TTL3I 

TTL3Ia 

interpretation . 

Develop  test  suite: 

Construct  CGMs  to  test 

FIPS 

PUB  128 

syntax 

TTL3Ib 

conformance. 

Construct  CGMs  to  test 

MIL- 

-D-28003 

syntax 

TTL3IC 

TTL3Id 

TTL3Ie 


conformance. 

Constmjct  CGMs  to  test  Draft  Quality  conformance. 
Construct  CGMs  to  test  Publication  Quality 
conformance. 

Document  allowable  differences  for  Draft  Quality 
CGMs. 


TTL3If 

TTL4I 

TTL4Ia 

TTL4Ib 


Docximent  allowable  differences  for  Publication 
Quality  CGMs. 

Develop  support  tools: 

Develop  CGM  generation  utility. 

Develop  Test  Result  recording  utility  based  on  a 
DBMS. 


TTL5I 

TTL6I 

TTL6Ia 

TTL6Ib 

TTL6IC 

TTL6Id 

TTL6Ie 

TTL6If 

TTL7I 

TTL8I 

TTL8Ia 

TTL8Ib 


Design  the  test  reports. 

Develop  test  procedures; 

For  the  utility  programs. 

Operator  scripts  for  CGM  in  the  Test  Set. 
Maintenance  procedures. 

On-site  modifications. 

On-site  recordkeeping  requirements. 
Checklists  of  materials. 

Document  how  to  evaluate  test  results. 
Participate  in  field  tests: 

Alpha  field  test. 

Beta  field  test. 
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TeQile  3-3.  Tasks  Associated  with  Testing  Lciboratory  Operation 
and  Client  Responsibilities  with  respect  to  CGM  Interpreter 
Testing  ( Continued ) 


Task  ID 


Task  Description 


TTL9I 

TTL9Ia 

TTL9Ib 

TTL9IC 

TTL9Id 

TTLIOI 

TTLllI 


Refine  test  method  as  result  of  field  tests: 

Design  changes  to  Test  Set  after  alpha  results 
known. 

Implement  alpha  changes. 

Design  changes  to  Test  Set  after  beta  results 
known. 

Implement  beta  changes. 

Negotiate  license  terms  and  conditions. 

Develop  change  control  procedures  for  the  test  method. 


TCLII  Specify  steps  to  be  followed  by  client. 

TCL2I  Specify  information  needed  from  client. 
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Table  3-4.  Tasks  Associated  with  the  Certification  Body 

(all  estimates  in  man-weeks) 


Task  Id 

Phase  1 

Phase  2 

Phase  3 

Phase  4 

Phase  5 

Phase  6 

TCBl 

1.5 

0.5 

_ — 

2.0 

— 

1.0 

TCB2 

in 

• 

o 

0.5 

— 

2.0 

— 

TCB3 

2.0 

2.0 

2.0 

4.0 

TCB4 

3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

TCB5 

1,0 

mgm 

1.0 

1.0 

1.0 

1.0 

TCB6 

— 

— 

— 

1.0 

— 

TCB7 

— 

— 

— _ 

1.0 

— 

mm 

TCB8 

— 

— 

— 

1.0 

— 

1.0 

TCB9 

— 

— 

— - 

4.0 

— 

4.0 

TCBIO 

— 

— 

— 

6.0 

— 

14.0 

TCBll 

— 

.  — 

— 

2.0 

— - 

mam 

TCB12 

3.0 

1,0 

— 

— 

3.0 

TCB13 

2.0 

0.5 

1.0 

1.0 

— 

0.5 

Totals 

13.0 

8.5 

7.0 

30.0 

8.0 

42.5 
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Table  3-5.  Tasks  Associated  with  Testing  LedDoratory  Operation 

and  Client  Responsibilities  with  Respect  to  CGH 
Generator  Testing 

(all  estimates  in  man-weeks) 


*  Assumes  the  availability  of  a  baseline  implementation. 
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V.  ASSESSMENT  OF  IMPACT  ON  CGM  TESTING 


1.0  Impact  on  the  CALS  Program 

Implementation  of  a  full  CGM  (MIL-D-28003)  testing  program  is 
vital  if  CALS  is  to  reap  the  benefits  of  interoperability 
potentially  offered  by  conforming  CGM  interpreters  and 
generators . 

More  than  most  information  processing  standards  and  typical  of 
data  interchange  standards  (like  IGES) ,  the  CGM  standard  offers 
implementors  a  wide  range  of  options.  Files  can  be  tested  for 
conformance  to  the  standard,  but  interoperability  is  not 
guaranteed  even  when  conforming  CGMs  are  used  for  interchange. 
This  situation  results  when  the  options  selected  by  the 
generating  program  do  not  match  the  options  supported  by  all  the 
target  interpreting  programs. 

Until  and  unless  CALS  supports  the  development  of  a  formal 
testing  program  for  MIL-D-28003,  the  full  potential  of  CGM  as  a 
compact,  efficient,  euid  powerful  data  interchange  format  for 
geometric  graphic  information  (as  contained  in  technical 
drawings,  for  exeunple)  cannot  be  realized.  In  the  absence  of 
testing  to  the  CALS  Application  Profile,  commercial  companies 
will  use  only  a  minimal  subset  of  CGM  (just  as  they  have  done  for 
IGES) .  Consequently,  the  resulting  files  will  be  less  compact 
and  more  costly  to  transmit,  store,  and  process.  In  addition, 
they  might  poorly  represent  the  intended  picture  as,  for  example, 
when  an  ellipse  or  circle  is  replaced  by  a  series  of  line 
segments.  On  a  high  resolution  display,  the  resulting  image  will 
appear  a  lot  rougher  than  it  would  have  appeared  had  the  basic 
geometric  elements  been  stored  in  the  CGM  rather  than  the 
straight-line  approximations. 

The  testing  program  should  meet  the  general  requirements  set  out 
in  the  proposed  FIPS  for  Conformance  Testing  (Reference  8)  . 
These  issues  are  discussed  further  in  section  VI. 


2.0  Impact  on  the  Commercial  Marketplace 

The  results  of  section  III,  subsection  4  show  that  all  providers 
of  CGMs  will  have  to  develop  a  new  release  of  their  software  in 
order  to  meet  the  requirements  of  any  CALS  Application  Profile. 
Given,  then,  that  a  new  release  will  be  required,  in  this 
section,  an  estimate  of  the  amount  of  resources  that  the  typical 
implementor  will  have  to  expend  in  order  to  satisfy  the  CALS  AP 
is  given. 
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2.1  Constraints  on  Element  Usage  and  on  Options 

The  most  important  thing  to  note  is  that  meeting  most  the 
requirements  of  the  AP  will  be  very  easy  for  implementors. 
Restrictions  on  the  encoding,  types,  and  precisions  are  easy  to 
build  in — either  as  the  only  option  available  or  as  a  restriction 
controlled  by  some  sort  of  software  "switch,"  selectable  at 
run-time  by  the  operator  of  the  program  generating  the  metafile. 
Many  other  AP  constraints — avoiding  private  ESCAPES,  GDPs,  and 
out-of-range  enumerated  types — can  also  be  met  when  the  "CALS 
switch"  is  set. 

Some  implementors,  especially  those  using  Henderson  Software's 
basic  libraries,  already  are  prepared  for  this  sort  of  thing. 
They  have  implemented  the  constraints  of  the  TOP  3.0  Application 
Profile  for  CGM  in  a  similar  manner.  To  minimize  the  impact  on 
these  suppliers  and  because  of  the  wide  publicity  concerning  the 
TOP  CGM  AP,  it  may  be  desirable  to  have  a  level  of  CALS  CGM  AP 
conformance  be  identical  to  that  of  TOP.  This  is  being  strongly 
considered  as  a  change  to  MIL-D-28003  for  FY  '89. 

Many  of  the  CALS  AP  constraints  and  requirements  can  be 
implemented  with  literally  a  few  lines  of  code.  Others  are 
straightforward,  but  require  more  effort.  For  example,  if  the 
application  generating  the  CGM  uses  private  (i.e., 
non-standardized)  line  types,  marker  types,  or  hatch  patterns, 
the  CGM  generator  logic  either  will  have  to  map  the  value  into  a 
supported  CALS  value  (8  special  line  types  and  18  special  hatch 
patterns  are  allowed)  or  will  have  to  simulate  the  desired  visual 
effect  by  using  other  legal  CGM  elements,  like  POLYLINE  and 
POLYGON. 

In  a  similar  fashion,  programs  that  use  GDPs  and  ESCAPES  to 
achieve  certain  visual  effects  will  have  to  draw  upon  the 
supported  CGM  elements  (19  graphical  primitives  and  35 
attributes)  to  achieve  the  desired  effect.  Depending  upon  the 
sophistication  of  the  desired  effect,  the  programming  effort 
might  be  simple  or  very  complex. 

2.2  The  Color  Table  and  Fonts 

In  two  areas  of  MIL-D-28003,  education  of  the  suppliers  is 
needed;  use  of  the  color  table  and  use  of  fonts.  The  cooperation 
that  arises  when  planning  for  industry  demonstrations  like  CALS 
EXPO  and  NCGA's  Integrate '89  is  a  good  focal  point  and 
opportunity  for  teaching  the  implementors  what  was  intended  by 
the  Application  Profile. 

In  most  cases,  proper  use  of  the  COLOUR  TABLE  element  will  not  be 
expensive  to  implement:  in  fact,  most  products  almost  work 
correctly.  It's  just  that,  in  some  of  them,  no  Color  Table  is 
written  at  all  and,  in  others,  some  color  indices  are  used  but 
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not  set.  This  opens  the  door  to  non-predictable  results  upon 
interpretation  of  the  CGM.  This  might  be  tolerable  for  Draft 
Level  quality  interchange,  but  it  cannot  be  accepted  for 
Publication  Level  quality  interchange. 

Proper  use  of  the  elements  relating  to  fonts  will  require  more 
education  and  more  programming  effort  to  get  working  correctly. 
The  CGM  scheme  is  based  on  long-standing  ISO  and  ANSI  standards 
developed  by  the  Codes  and  Character  Set  committees.  These 
standards  distinguish  between  a  character  set  (a  collection  of 
glyphs  that  comprise  an  alphabet)  and  a  font  (the  appearance  of 
the  characters  united  by  a  unique  stylistic  theme) .  For  now,  it 
is  important  to  get  people  to  use  the  following  elements 
properly; 

FONT  LIST 
CHARACTER  SET  LIST 
CHARACTER  CODING  ANNOUNCER 
TEXT  FONT  INDEX 
CHARACTER  SET  INDEX 
ALTERNATE  CHARACTER  SET  INDEX 

The  bad  news  is  that  few,  if  any,  CGM  generating  and  interpreting 
systems  have  a  text  environment  that  utilizes  the  concepts  of  ISO 
2022,  which  provides  the  mechanism  for  alternately  selecting  from 
among  several  character  sets.  The  good  news  is  that  the  default 
values  for  most  elements  are  consistent  with  the  common  text 
environments  familiar  to  most  implementors.  Section  VI  discusses 
some  more  suggestions  relating  to  text  and  the  proper  selection 
of  fonts. 

2.3  Pareimeter  Size  Limits 

Most  of  the  size  limitations  (e.g.,  restricting  point  arrays  to 
1024  points)  are  reasonable  and  necessary  so  as  to  not  put  an 
undo  burden  on  interpreters.  However,  for  certain  purposes,  the 
constraints  on  CELL  ARRAY  and  PATTERN  TABLE  might  be  too 
limiting.  If  one  needs  to  use  CELL  ARRAY,  constraining  its  use 
to  one  1024  x  1024  array  might  be  much  too  limiting.  However, 
there  is  no  empirical  evidence  to  support  any  particular 
limitation. 

The  same  point  holds  true  for  PATTERN  TABLE.  But,  in  this  case, 
all  those  companies  that  can  generate  or  interpret  the  PATTERN 
TABLE  element  have  chosen  to  permit  more  than  the  space  occupied 
by  eight  16  x  16  patterns. 

These  issues  are  discussed  further  in  section  VI,  where  it  is 
argued  that  perhaps  a  special  AP  level  is  required  for  CGMs  that 
use  CELL  ARRAY  and  PATTERN  TABLE. 

2.4  Physical  File  Structure 
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The  80-octet  fixed  length  records  proposed  by  MIL-D-28003  are 
supported  by  only  a  very  few  of  the  current  CGM  suppliers.  On 
PCs  and  on  UNIX  workstations,  the  more  usual  format  is  an 
unstructured,  continuous  stream  of  octets. 

Converting  one's  program  to  output  80-character,  fixed-length 
records  is  not  difficult  or  expensive,  but  it  might  encounter 
some  emotional  resistance  from  developers.  Perhaps,  developers 
instead  will  offer  a  simple  utility  that  takes  in  a  CGM  as 
continuous  stream  of  octets  and  produces  a  CGM  with  the  correct 
physical  format. 

3 . 0  Summary 

The  net  impact  on  the  suppliers — from  a  time  and  materials  point 
of  view — is  not  very  great.  Most  current  CGM  generators  could  be 
converted  to  conforming  CALS  AP  generators  with  less  than  two 
man-months  effort  by  the  original  developers. 

One  CEumot  make  a  similar  estimate  for  CGM  interpreters,  because 
the  extent  of  the  work  required  depends  upon  how  rich  and  robust 
the  current  implementation  is.  All  will  have  to  add  support  for 
the  new  CALS  line  types  and  hatch  patterns  and  the  three  new  CALS 
ESCAPES.  Many  will  have  to  add  support  for  the  16  Hershey  fonts 
specified  in  MIL-D-28003  and  most  will  have  to  implement  the  full 
text  model  (e.g.,  designating  and  selecting  character  sets 
according  to  ISO  2022;  support  for  changing  text  attributes 
within  a  sequence  of  RESTRICTED  TEXT,  APPEND  TEXT,  and  TEXT 
elements)  assumed  by  the  CGM.  Finally,  for  Publication  Level 
quality  conformance,  it  is  likely  that  nearly  all  current 
implementations  will  have  to  be  improved  to  meet  the  guidelines 
specified  in  Annex  D  of  the  CGM  standard  and  mandated  by  the  CALS 
AP  for  conforming  interpreters.  The  rest  of  the  CALS  AP 
requirements  are  trivial  for  interpreters  to  meet,  if  the 
interpreter  already  supports  the  full  set  of  elements  contained 
in  the  ANSI  standard. 

The  principal  impediment  to  improved  CALS  CGM  interpreters  is 
that  most  current  interpreters  are  built  upon  other,  older 
technology  developed  before  the  CGM  was  adopted  as  a  standard  or 
known  to  the  developers.  In  order  to  meet  the  full  requirements 
of  the  CALS  AP  for  publication  quality  interpreters,  these 
products  will  need  to  be  redesigned  and  re- implemented  with  the 
CGM  and  CALS  requirements  firmly  in  mind  from  the  beginning.  This 
is  as  it  should  be;  the  long-term  CALS  needs  for  quality 
publications  involving  text  and  graphics  are  too  important  to  be 
sacrificed  in  favor  of  the  short-term  desires  of  industry  to 
reuse  existing  code.  The  Draft  conformance  level  is  affordably 
attainable  by  those  companies  seeking  to  quickly  bring  a  product 
to  market,  utilizing  pre-CGM  technology. 
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VI .  RECOMMENDATIONS 


1.0  For  CALS  Certification  of  CGMs 

As  a  result  of  this  task,  NIST  has  developed  a  number  of 
recommendations  for  CALS.  [Note:  They  are  the  statements  made  in 
bold  print  in  the  sections  below. ] 

MIL-D-28003  contains  the  concepts  of  a  conforming  basic  generator 
and  a  conforming  basic  interpreter.  A  conforming  basic 
interpreter  can  conform  to  one  of  two  levels,  Publication  and 
Draft.  Certification  of  conforming  basic  generators  is  examined 
separately  from  conforming  basic  interpreters. 


2.0  Conforming  Basic  Generator 

Essentially,  a  conforming  basic  generator  is  defined  as  one  that 
produces  only  conforming  basic  metafiles  (or  can  be  commanded  to 
function  in  that  mode) . 

In  theory,  one  must  test  all  possible  CGMs  producible  from  a 
generator-under-test  in  order  to  verify  that  all  such  CGMs  are 
conforming  basic  metafiles.  This  is  clearly  unrealistic.  An 
alternate  theoretical  approach  would  be  to  prove — in  some  formal 
sense — that  the  generator  program  was  incapable  of  writing  a 
non-conforming  basic  metafile.  This,  too,  is  beyond  the  state  of 
the  art.  In  fact,  any  examination  of  the  generator  program 
itself  would  be  prohibitively  expensive  to  administer  and  would 
produce,  at  best,  unreliable  and  unreproducible  results. 

How  then  can  generator  confoinnance  be  tested?  The  only  workable 
approach  is  to  examine  a  representative  sample  of  the  output  of 
the  generator-under-test  and  verify  that  each  CGM  is  indeed  a 
basic  conforming  metafile.  Consequently,  NIST  recommends: 

A  reference  interpreter  capable  of  testing  and  reporting 
whether  a  CGM-under-test  is  a  CALS  basic  conforming  metafile 
must  be  developed. 

If  the  CGM-under-test  fails  the  test,  the  report  should 
indicate  in  what  ways  the  CGM-under-test  is  non-conforming. 

A  standardized  form,  to  be  filled  out  by  implementors  for 
their  generator-under-test,  and  a  sampling  methodology  must 
be  developed  in  order  to  specify  exactly  how  many  CGMs  must 
be  provided  for  the  test  sample  and  what  the  characteristics 
of  those  CGMs  must  be. 

This  is  a  non-trivial  task  and  will  require  a  great  deal  of 
careful  thought. 
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3.0  Conforming  Basic  Interpreter 

The  only  practical  way  to  validate  an  interpreter-under-test  is 
to  provide  it  with  a  large  set  of  basic  conforming  metafiles  and 
observe  its  behavior  and  the  visible  results  of  interpretation  as 
it  attempts  to  process  each  CGM.  Consequently, 

CALS  needs  to  acquire  a  CGM  Test  Set  along  with  associated 
test  administrator  instructions  for  the  validation  of  CGM 
interpreters . 

This  technique,  known  as  falsification  testing,  can  only 
prove  an  implementation  non-conforming.  Successful 
processing  of  all  test  cases  does  not  guarantee  perfect 
conformance;  however,  a  well  chosen  test  set  can  boost 
confidence  in  the  functioning  of  the  interpreter-under-test 
to  very  high  levels. 

Because  of  the  large  number  of  features — both  syntactic  and 
semantic — that  need  to  be  tested,  NIST  suggests  that 

A  large  number  of  groups  of  test  sets  should  be  developed. 

Each  group  should  concentrate  on  a  few  closely-related 
aspects  of  conformance.  For  example,  on  the  use  of  Metafile 
Descriptor  Elements  or  on  the  correct  interpre£ation  of  the 
text  primitives  and  attributes.  The  initial  group  developed 
should  be  a  broad  collection  of  CGMs  representative  of  the 
actual  engineering  and  technical  drawings  that  are  expected 
to  be  transferred  in  a  CALS  application. 

Because  of  the  need  to  tailor  the  test  cases  to  check  for  a  wide 
selection  of  variations  and  for  certain  exceptional  conditions, 
NIST  also  suggests  that 

A  CGM  creation  tool,  probably  based  on  the  CGM  Clear  Text 
Encoding,  should  be  implemented  so  that  needed  CGM  test  sets 
can  be  developed  in  a  timely  and  cost-effective  manner. 

This  tool  must  be  capable  of  creating  both  conforming  and 
non-conforming  CGMs  in  order  to  verify  the  proper 
functioning  and  robustness  of  interpreters-under-test. 


4.0  Additional  Remarks  Regarding  Cezrtification 

Before  leaving  the  topic  of  certification,  NIST  makes  the 
following  observations; 
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o 


Most  CGM  implementations  have  been  developed  in  the  US 
and  reflect  US  market  imperatives. 

o  Any  certification  based  on  ISO  8632  or  ANSI  X3.1^2 
alone,  while  necessary  for  CALS,  is  insufficient  to 
guarantee  the  interoperability  required  by  CALS. 

o  The  CGM  has  the  potential  to  be  a  very  cost-effective 
and  well-supported  standard  for  the  US  Government,  if 
an  effective  certification  scheme  can  be  implemented  in 
a  timely  fashion. 

Therefore,  NIST  concludes; 

It  is  vital  that  the  US  take  the  international  initiative  in 
the  certification  and  testing  of  CGM  implementations  and 
that ,  the  CALS  needs  for  testing  against  its  Application 
Profile  drive  the  US  certification  efforts. 

Furthermore,  NIST  notes  that  the  number  and  variety  of 
implementations  purporting  to  generate  CALS  conforming  basic 

metafiles  should  exceed  the  number  of  CALS  conforming 

interpreters  needed  by  the  Government  and  industry  and  that  a 
greater  part  of  the  testing  of  generators  can  be  automated  than 
the  testing  of  interpreters.  Consequently,  NIST  suggests; 

Testing  for  CALS  basic  conforming  metafiles  should  have 
higher  priority  than  testing  for  CALS  basic  confozming 

interpreters . 

Essentially,  in  the  short  term,  it  is  more  important  to  have  a 
large  collection  of  conforming  generators  producing  a  vast 
selection  of  basic  conforming  metafiles  for  interpreters  to 
attempt  to  handle  than  it  is  to  have  fully  conforming 

interpreters  without  a  lot  of  conforming  CGMs  for  them  to 
interpret. 
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FINAL  PHASE  I.l  CGM  MILSPEC 


I.  PURPOSE 

Update  the  draft  CGM  Application  Profile  (AP)  for  CALS  based  on 
DoD/Industry  Coordination  Reviews,  and  coordination  with  the  TOP 
Application  Profile.  Produce  final  Phase  I.l  CGM  MILSPEC  (CALS 
SOW  Task  3. 1.2. 2)  . 


II.  BACKGROUND 
1.0  Overview  of  CGM 

The  Computer  Graphics  Metafile  (CGM)  standard,  ANSI  X3. 122-1986 
and  ISO  8632/1-4,  specifies  the  syntax  and  semantics  of  a 
standard  file  format  for  storing  and  communicating  computer 
graphics  pictures.  By  intentional  choice  of  scope  the  CGM 
specification  is  limited  to  the  syntax  and  semantics  of  a  set  of 
CGM  ''elements'*  for  the  device-independent  description  of  computer 
graphics  pictures. 

In  the  two  years  that  it  has  been  an  ANSI  standard  CGM's  use  and 
its  incorporation  into  other  standard  interface  and  exchange 
specifications  has  been  increasing.  The  number  of  commercially 
available  implementations  continues  to  increase.  For  the  first 
time  in  1988,  test  sets  for  interpreters  and  output  analysis 
programs  for  generators  have  become  commercially  available.  This 
alleviates  one  of  the  problems  that  has  been  retarding  expansion 
of  CGM  support. 

CGM  has  been  designated  as  a  Federal  Information  Processing 
Standard  (FIPS  PUB  128)  .  It  has  been  incorporated  as  the 
graphical  metafile  of  the  TOP  (Technical  Office  Protocol) 
specification  (see  Appendix  A  for  the  final  text  of  this 
specification) .  It  is  designated  as  the  Geometric  Graphic 
Content  Architecture  of  the  ISO  (International  Standards 
Organization)  compound  document  standard  (ISO  8613,  aka 
"ODA/ODIF") .  CGM  may  be  included  in  SGML  (Standard  Generalized 
Markup  Language)  documents  for  definition  of  graphics  content. 
The  1987  CGM  Application  Profile  for  CALS  was  designated  as  the 
MIL-D-CGM  Military  Specification.  As  of  November  1988  it  is  now 
known  as  MIL-D-28003  (see  Appendix  B  for  the  final  text  of  this 
specification  as  of  November  18,  1988). 


2.0  Rationale  for  Application  Profiles 

The  syntactic  specification  of  the  CGM  standard  is  complete  a. id 
unambiguous.  The  semantic  specification  is  less  complete.  The 
expected  overall  results  of  using  the  geometric  primitive 
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elements  are  well  enough  specified.  However  some  of  the  finer 
details,  such  as  the  precise  appearance  of  joints  and  endpoints 
in  lines,  are  unspecified.  This  underspecification  of  semantics 
was  to  some  extent  intended  by  the  bodies  of  experts  who  devised 
the  CGM,  since  it  allows  a  wider  range  of  existing  systems  to  be 
accommodated  and  makes  the  standard  more  adaptable  to  the  varying 
needs  and  philosophies  of  CGM's  diverse  clientele. 

The  semantic  ambiguity  does  mean  that  there  will  be  no  single 
correct  interpretation  of  a  given  CGM,  and  hence  it  will  be 
difficult  to  unambiguously  describe  an  intended  picture  using 
CGM.  The  CGM  standard  also  specifically  excludes  standardization 
of  the  behavior  of  metafile  generators  and  metafile  interpreters, 
thereby  introducing  a  further  unpredictability  of  results  into 
the  graphics  and  application  system  viewed  as  a  whole.  These 
uncertainties  are  a  distinct  drawback  in  the  CGM  application 
areas  of  Technical  Illustration  and  Technical  Publishing,  which 
are  central  to  the  CALS  effort. 

It  is  primarily  to  remove  these  uncertainties  that  Application 
Profiles  (APs)  are  defined.  One  further  use  of  APs  is  to  extend 
the  functionality  of  the  standard  where  it  is  deemed  inadequate. 
At  the  start  of  the  CALS  AP  project  in  1987,  one  such  AP 
definition  was  in  progress —  the  CGM  Application  Profile  of  TOP. 
The  NIST  AP  project  progressed  in  close  collaboration  with  the 
metafile  experts  of  TOP,  with  the  intention  that  the  two  profiles 
should  be  identical  if  possible.  An  initial  specification  of  a 
CGM  Application  Profile  for  CALS  was  produced,  and  that 
specification  was  very  close  to  the  TOP  specification  (which  was 
itself  extensively  revised  as  a  result  of  the  collaborative 
efforts)  in  those  areas  where  the  two  APs  overlap.  The  CALS  AP 
goes  further  in  its  specifications. 


3 . 0  The  Necessity  of  Updating  the  CALS  AP 

It  was  recognized  at  the  end  of  the  project  for  the  initial 
version  of  the  CALS  AP  that  future  work  would  be  required  and  an 
updated  Application  Profile  should  be  produced.  In  part  this  is 
necessary  because  there  were  not  sufficient  time  and  resources  to 
resolve  all  of  the  technical  issues  and  the  complex  set  of 
relationships  between  the  CALS  AP  effort  and  other  official  and 
de  facto  standards  work;  in  part  it  is  necessary  because  events 
in  1988  provided  real  world  experience  and  feedback  on  CGM  and 
the  APs;  and  finally  because  closely  related  specifications  and 
standards,  with  which  the  CALS  AP  must  be  compatible  or  upon 
which  it  depends,  have  continued  to  change  and  evolve  in  1988. 


4 . 0  Present  Work 
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During  1988  both  of  the  APs  have  been  reviewed,  and  there  have 
been  real-world  demonstrations  (e.g.  Integrate  '88  at  the 
National  Computer  Graphics  Association  (NCGA)  Conference)  of 
multi-vendor  systems  integration  based  on  Application  Profiles  of 
CGM.  Information  that  has  been  generated  from  these  and  a  number 
of  additional  sources  has  pointed  to  the  necessity  to  revise  and 
extend  the  initial  draft  of  the  CALS  AP. 

The  final  report  of  this  project  in  1987  contains  considerable 
technical  detail  about  the  requirements,  scope,  and  goals  of  the 
CALS  application  profile.  It  contains  as  well  information  on  the 
sources  of  technical  specification  for  the  CALS  AP,  details  of 
the  TOP  profile,  and  the  history  and  process  of  deriving  the  CALS 
AP  and  reconciling  it  with  the  TOP  AP.  The  remainder  of  this 
current  report  will  focus  on  the  activities  to  revise  the  initial 
CALS  AP  in  1988,  will  present  the  final  results,  discuss 
reconciliation  with  TOP,  and  finally  identify  what  needs  to  be 
done  in  1989  with  regard  to  the  CALS  AP. 


III.  DISCUSSION 


1.0  Major  Activities 

The  following  activities  comprise  most  of  the  work  to  date  in 
1988  for  the  CALS  AP  Update  project. 


1.1  Review  and  Comparison  of  Final  CALS  '87  and  TOP 
Specifications 

The  final  TOP  specification  became  available  in  April  1988  (see 
Attachment  A) .  The  MIL-D-CGM,  which  was  prepared  from  the  final 
text  of  the  CALS  AP  '87,  became  available  in  April  1988.  All  of 
these  documents  have  been  reviewed  for  correctness  and 
consistency-  In  addition,  review  comments  from  independent 
experts  and  other  reviewers  have  been  received  and  considered. 
Changes  to  both  the  TOP  AP  and  MIL-D-CGM  resulted. 


1.2  Evaluation  of  Initial  Experience  with  CALS  AP 

At  NCGA  '88  there  was  for  the  first  time  a  substantial  multi¬ 
vendor  demonstration  of  system  integration  using  CGM.  The  TOP 
and  CALS  APs  were  not  specifically  required  of  participants. 
Never-the-less,  some  of  the  requirements  were  based  on  the  APs, 
some  were  based  on  variations  of  specifications  from  the  APs,  and 
some  vendors  used  TOP/CALS  conforming  generators  and 
interpreters.  In  addition,  experience  has  been  gained  during  the 
real  work  of  building  implementations  and  constructing  test  sets. 
All  of  this  experience  has  been  evaluated  for  lessons  about  the 
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strengths  and  deficiencies  of  the  APs.  Significant  changes  to 
MIL-D-CGM,  particularly  in  the  area  of  color,  have  resulted. 


1.3  Colladjoration  with  TOP  Experts 

Consultation  and  discussion  with  the  experts  responsible  for  the 
TOP  profile  has  continued  and  will  continue.  The  TOP  profile  is 
soon  to  be  printed  in  final  form.  A  number  of  "editorial" 
changes  have  been  produced  (for  both  TOP  and  CALS),  and  a  number 
of  substantial  changes  are  being  discussed  for  the  TOP  revision 
cycle.  Discontinuing  independent  development  of  the  TOP  AP,  in 
favor  of  a  single  AP  based  on  the  CALS  AP  '87  and  its  updates, 
has  been  discussed. 


1.4  Registration  Proposals 

Two  sets  of  registration  proposals  of  interest  to  CALS  are  being 
processed.  First,  there  is  a  set  of  linotypes  and  hatch  styles 
from  engineering  practice.  These  were  included  in  the  CALS  AP 
'87.  These  have  been  submitted  for  Graphical  Registration  within 
ISO  (with  ANSI  being  the  reviewer  and  submitter) .  The  progress 
of  these  proposals  has  been  tracked.  Second,  a  set  of 
registration  proposals  for  extended  geometric  functionality 
(conics,  splines,  etc)  that  were  not  included  in  CALS  AP  '87  have 
been  submitted  for  registration.  These  have  been  followed  and 
evaluated  as  well.  Changes  to  MIL-D-CGM  have  resulted. 


1.5  Tracking  and  Evaluation  of  Other  Related  Specifications 

CALS  AP  '87  attempted  to  specify  font  naming  by  reference  to  ISO 
9541.  At  the  time  the  TOP  AP  was  written  (upon  which  the  CALS  AP 
'87  was  based),  ISO  9541  was  at  Draft  Proposal  (DP)  stage. 
Changes  have  since  occurred  and  are  still  occurring.  These  have 
been  studied  and  evaluated.  Changes  to  both  TOP  and  MIL-D-CGM 
have  resulted — mainly  it  is  considered  premature  to  try  to 
formulate  font  name  specifications  according  to  the  unstable  DI3 
(Draft  International  Standard)  ISO  9541. 

There  is  significant  overlap  between  CALS  AP  '87  and  the 
specification  of  CGM  in  ISO  8613  Part  8,  which  is  ODA/ODIF 
Geometric  Graphics  Content  Architecture.  This  specification  has 
been  tracked  and  commented  on.  Minor  changes  to  TOP,  CALS,  and 
ODA/ODIF  resulted.  However  ODA/ODIF  introduced  further  changes 
without  consultation  or  review  at  the  stage  of  producing  final 
text,  and  has  introduced  flaws.  These  will  not  be  repeated  in 
the  CALS  and  TOP  APs. 

Finally,  the  existence  of  an  "implementors  agreement"  related  to 
8613/8  (an  NBS  Document  Application  Profile)  was  belatedly 
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discovered.  It  is  believed  to  be  essentially  the  same  as  8613/8. 
The  previous  comments  on  ODA/ODIF  apply  here  as  well. 


1.6  Evaluation  of  Functional  Extensions 

The  second  set  of  registration  proposals,  mentioned  above,  and 
the  preliminary  content  of  the  CGM  addenda  (Addendum  1  and 
Addendum  3)  deal  with  this  set  of  functional  extensions,  which 
are  important  to  the  CALS  constituency.  The  work  is  being 
followed  carefully.  Strategies  for  relating  and  coordinating  the 
AP  to  the  content  of  this  work  are  being  considered.  No  changes 
to  MIL-D-CGM  have  resulted  so  far. 


1.7  Review  Comments  by  CALS  Industry  Standards  Group 

A  CALS  industry  standards  working  group  met  to  consider  comments 
on  MIL-D-CGM.  Comments  were  received,  classified,  discussed,  and 
responded  to.  The  dispositions  included  rejection,  acceptance, 
acceptance  with  modification,  and  deferral.  The  last  category 
were  deferred  to  NIST  for  processing.  All  of  the  comments  and 
dispositions  were  reviewed  as  well.  In  a  few  cases  NIST 
recommended  modifications  of  the  initial  dispositions.  Changes 
to  MIL-D-CGM  resulted  from  this  review. 


1.8  Review  Comments  from  DoD 

In  September  1988  comments  on  MIL-D-CGM  were  received  from 
Department  of  Defense  for  processing.  There  was  no  initial 
screening  of  these  comments.  30+  comments  were  processed  and 
dispositions  recommended  for  them.  Changes  to  MIL-D-CGM 
resulted  from  processing  these  comments. 


2.0  Specification  of  Changes  to  Draft  MIL-D-CGM 

As  a  result  of  the  previous  activities  the  following  changes  are 
recommended  for  CAL  AP  '87 — MIL-D-CGM. 


2.1  Examples  of  Line/Hatch  Styles 

An  appendix  will  be  added  that  gives  examples  of  the  engineering 
line  and  hatch  styles.  The  hatch  style  examples  are  taken  from 
Y14.M.  The  line  type  examples  are  taken  from  a  recent  draft  of 
the  registration  proposals.  They  are  included  in  Attachment  A  to 
this  report.  When  the  proposals  are  finally  accepted,  the 
examples  should  be  replaced. 
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2.2  Errors  in  the  ANSI/FIPS  Standard 

A  number  of  harmless  editorial  errors  have  been  found.  In 

addition,  a  number  of  error  of  substance  (but  due  to  editorial 
causes)  have  been  found.  These  should  be  included  in  the  updated 
MIL-D-CGM,  as  a  subsection  of  Section  6,  or  as  a  new  Section  7, 
or  as  another  appendix. 

1.  ANSI  CGM  has  an  error  that  was  corrected  in  ISO  CGM. 
On  p.lOO,  the  last  item  on  the  page;  '•1”  should  be  "0" 
and  "foreground”  should  be  "background”. 

2.  In  ANSI  CGM  (and  ISO),  Part  3,  p.l7,  item  11:  the 

fraction  numerator  which  is  "pnx”  should  be  ”pnx-l”. 

3.  In  ANSI  CGM  (and  ISO),  Part  3,  p.26,  VDC  REAL 

PRECISION:  "31"  should  be  "E,2I”. 

4.  In  ANSI  CGM  (and  ISO),  Part  1,  clause  5.2.1,  clause 

5.3.12,  clause  6:  it  is  unclear  and  contradictory 

whether  Metafile  Descriptor  elements  return  to  default 
at  Begin  Picture,  and  whether  they  can  be  included  in 
the  Metafile  Defaults  Replacement.  The  answer  is  "no” 
on  both  points. 

5.  In  ANSI  X3. 122-1986,  Part  1,  p.l06,  the  expansion  of 

"<metafile  contents>":  the  "j”  symbols  should  be 

deleted. 


2.3  Order  of  Metafile  Descriptor  Elements 

It  is  unclear  in  the  CGM  standard  whether  there  should  be  a 
mandatory  ordering  of  Metafile  Descriptor  elements  (the  grammar 
implies  some)  .  The  CGM  extension  experts  feel  that  the  order 
should  be:  Metafile  Version,  Metafile  Element  List,  Metafile 

Description.  CGM  Addendum  1  will  impose  such  an  ordering.  This 
specification  will  be  put  into  the  AP  in  a  future  revision,  when 
the  AP  is  based  on  Addendum  1.  It  should  be  suggested  in 
3. 2. 1.2,  pointing  out  that  it  may  be  mandatory  in  a  future 
revision. 


2.4  Partitioning  is  Legal  for  non-MDR  Elements 

Add  a  sentence  to  the  3. 2. 7.1  at  the  end  of  Description  for 
Metafile  Defaults  Replacement:  "Partitioning  is  permitted  for 
all  other  elements." 


2.5  Editorial  Consistency 
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Insure  that  all  references  to  ''conforming...”  read  "conforming 
basic  metafile”,  or  "conforming  basic  generator”,  or  "conforming 
basic  interpreter",  as  the  case  may  be.  That  is,  the  word  order 
should  be  "conforming  basic  <xxx>".  See  3.2.8. 1  for  an  example 
that  needs  fixing. 


2.6  Fix  Typographic  Errors 

In  2.1.1,  "availcable"  should  be  available;  "fromshall"  should  be 
"from";  "department"  should  be  capitalized. 


2.7  Note  about  Tape  Blocking 

The  final  text  for  the  TOP  AP  and  the  submitted  text  for  the  CALS 
AP  '87  both  had  a  second  sentence  in  3.1.5:  "When  files  are  being 
transmitted  on  magnetic  tape,  the  80-octet  logical  records  should 
be  blocked  into  800-octet  physical  records."  If  this  was  not 
removed  for  a  reason,  it  should  be  restored.  Also,  change 
"application  profiles  conforming"  to  "conforming  basic 
metafiles" . 


2.8  Fix  Alignment  in  Table  I 

The  word  "Announcer"  should  be  indented  to  emphasize  that  it  is 
part  of  the  previous  name,  continued  on  the  second  line.  Or  else 
put  it  all  on  one  line  if  it  will  fit. 


2 . 9  Change  MILCGM 

The  name  MILCGM  in  Note  1  of  Table  I  should  be  changed  to 
MIL-D-28003. 


2.10  Fix  Numbering  of  Notes  for  Table  1 

Move  the  content  of  Note  4  to  Note  2.  Move  the  content  of  Note  2 
to  Note  3.  Move  the  content  of  Note  3  to  Note  4. 


2.11  Editorial  Improvement 

In  3. 2. 1.3,  delete  the  sentence  beginning  "This  is  not  an 
error. . . " . 


2.12  Note  Explaining  VDC 
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Below  table  II  add  "Note;  VDC  stands  for  Virtual  Device 
Coordinates,  the  coordinate  system  of  CGM  FIPS  128. 


2.13  Delete  Hatch  Style 

Remove  "earth"  the  earth  style  from  Table  V,  because  it  has  been 
withdrawn  from  registration  (it  can  be  made  with  "rock"  and 
"sand").  Note:  "across  grain  wood",  "with  grain  wood",  and 
"water  and  other  liquids"  have  been  reformulated  to  meet  critical 
objections  and  have  been  resubmitted  to  registration.  They  are 
lagging  one  step  behind  the  others  now. 


2 . 14  Add  Linetypes 

Add  to  Table  IV  the  two  linetypes 

break  line,  style  1  -11309 
break  line,  style  2  -11310 


2,15  Clarify  view  Surface  Clearing 

Rewrite  3. 2. 4.1:  "Unless  clearing  is  suppressed  by  'Escape  -301', 
the  view  surface  shall  be  cleared  upon  interpretation  of  the 
Begin  Picture  Body  element. 


2 . 16  Clipping  Description 

Rewrite  3. 2. 4.1:  "When  the  clip  indicator  is  'off,  clipping 
shall  be  done  to  the  intersection  of  the  device  viewport  and  the 
device  view  surface  limits.  When  clipping  is  'on',  clipping 
shall  be  done  to  the  intersection  of  the  clip  rectangle,  the  VDC 
extent,  the  device  viewport  and  the  device  view  surface  limits." 


2 . 17  Revise  Hershey  Font  Names 

Throughout,  replace  "Hersey"  with  "Hershey".  In  3.2.5,  replace 
the  three  sentences  beginning  with  "[NOTE:  The  font..."  by  "Font 
names  will  be  specified  in  a  manner  compatible  with  ISO  954  1, 
Font  and  Character  Information  Interchange,  when  it  becomes 
stable.  At  this  point  the  font  name  is  the  concatenation  of  the 
string  "HERSHEY:",  to  designate  one  of  the  Hershey  fonts,  and  a 
"name  string"  to  designate  the  particular  typeface." 


2.18  Default  Viewport 
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Rewrite  section  3. 2. 6. 2:  "The  default  device  viewport  is  the 
largest  rectangular  area  of  the  screen.  The  viewport  is 
redefined  by  this  escape  element  by  specifying  two  corner  points. 
The  effective  viewport  is  the  largest  rectangle  in  the  viewport 
having  the  same  aspect  ratio  as  the  VDC  extent,  and  having  the 
same  lower-left  corner  as  the  viewport.  The  VDC  extent  is  mapped 
onto  the  effective  viewport  when  the  picture  is  interpreted.  The 
units  with  which  the  two  points  are  specified  are  real  fractions 
[0.0  to  1.0],  which  shall  be  applied  to  the  default  viewport.  If 
used,  this  Escape  must  appear  in  the  Picture  Descriptor.  If  the 
scaling  mode  has  been  set  to  metric,  then  the  device  viewport 
shall  have  precedence  —  the  scaling  mode  will  be  treated  as  if 
it  were  abstract. 


2.19  Additional  Generator  Constraints 

In  3. 2. 8.1,  change  "by  MODULO  onto  the  Basic  range"  to  "the 
default  value  for  that  attribute;" 


2.20  String  Length 

In  3. 2. 8. 3,  Maximum  String  Length,  change  256  to  254. 


2.21  Text  Bvmdle  Table 

In  table  VIII,  Text  Bundle,  change  character  expansion  in  the 
second  text  bundle  from  0.5  to  0.7. 


2.22  Reference  ANSI  X3. 122-1986 

In  2.1.1,  mention  that  FIPS  128  is  identical  to  ANSI  X3. 122-1986. 


2.23  Rename  Minimal  Conformance  Level 

In  3.1.2,  rename  "Minimal  Level"  to  "Draft  Level".  Make  same 
change  in  1.2.  Add  to  3.1.2,  or  somewhere,  a  sentence  explaining 
that  Publication  Level  is  intended  to  be  mandatory  for  final 
document  production,  and  Draft  Level  defines  a  level  that  is 
suitable  for  working  when  documents  are  in  development  or  draft 
stage  (Draft  Level  could  be  much  less  expensive  and  time 
consuming  to  produce) . 


2.24  Functionality  of  Draft  Level 

Delete  "MARKER  TYPE",  "LINE  TYPE",  "HATCH  INDEX",  "FONT  DESIGN" 
and  "EDGE  TYPE"  from  the  table  at  the  end  of  3.1.2.  Add  a 
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sentence  after  the  table:  "For  LINE  TYPE  and  HATCH  INDEX,  the 
interpreter  shall  have  the  capabilities  of  D.5  of  FIPS  PUB  128. 
However  the  interpreter  may  take  fallback  actions  for  the 
additional  linetypes  of  Table  IV  and  hatch  styles  of  Table  V. 


2.25  Restrict  TRANSPARENCY  in  the  Basic  Set 

Add  to  table  II  a  line  for  the  Transparency  element,  specifying 
the  Basic  values  to  be  "1  (on)". 


2.26  Clarify  the  GDP  Sections 

Rewrite  3. 2. 1.5:  "To  ensure  portability  and  predictability  of 
results,  conforming  basic  metafiles  shall  not  contain  any 
Generalized  Drawing  Primitive  (GDP)  elements.  Future  addenda  to 
this  profile  may  specify  GDP  elements  to  be  included  in  the  Basic 
set." 


2.27  Fix  Typo  in  Device  Viewport 

In  MIL-D-CGM,  section  3. 2. 6. 2,  the  example:  "-301"  should  be 

"-302". 


2.28  Requirement  for  Character  Set  List 

In  3.2.3,  delete  the  sentence  "Each  basic  conforming. ..( 1 ,  4/1)". 


2.29  Color  Table 
2.29. I  Minor  Changes 

In  3.2.3,  delete  the  last  two  sentences  of  the  paragraph, 
beginning  with  "FIPS  PUB  128...". 

In  3.2.7. 1,  Color  Table,  replace  the  second  sentence  with  "Any 
Color  Table  element  defining  the  representation  of  a  given  color 
index  shall  appear  in  the  picture  before  reference  to  that  index 
by  an  attribute  element  or  use  of  that  index  by  a  graphical 
primitive  element  (included  in  the  latter  is  implicit  use  of 
default  color  index  attribute  values  by  the  first  occurrence  of 
an  associated  primitive) .  Once  a  given  color  representation  is 
defined  and  used,  it  shall  not  be  redefined.  These  restrictions 
insure  that  interpreting  systems  without  dynamic  color  update 
capabilities  can  render  the  intended  picture  accurately." 
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2.29.2  Major  Color  Changes 

It  has  become  clear  that  the  default  color  specification  of  the 
TOP  profile  and  the  first  draft  of  the  MIL-D-CGM  profile  not  only 
fails  to  contribute  to  predictable  results,  but  in  fact 
positively  leads  to  unpredictable  results  in  some  circumstances. 
Other  color  problems  have  been  pointed  out  in  the  comments  on 
MIL-D-CGM.  The  color  handling  under  MIL-D-CGM  will  be  revised  as 
follows  in  an  integrated  solution  to  all  of  these  problems. 

In  section  3. 2. 1.6,  add  a  paragraph:  "For  indexed  color 

selection,  either  all  color  indexes  used  in  the  metafile  shall 
have  their  representations  defined  by  use  of  the  COLOR  TABLE 
element,  or  none  shall.  A  color  index  is  "used”  if  it  occurs  in 
an  element  selecting  a  color  value  to  be  applied  to  a  primitive 
(LINE  COLOR,  CELL  ARRAY,  etc) . 

Replace  first  sentence  of  3. 2. 8. 2  with:  "In  the  absence  of  any 

color  table  elements,  or  of  ESCAPE  -303  (see  3. 2. 6. 3),  in  the 
metafile,  conforming  basic  interpreters  shall  initialize  their 
color  tables  as  follows:  index  0  shall  be  set  to  white,  index  1 
shall  be  set  to  black,  and  indexes  2-254  shall  be  set  by  cyclic 
repetition  of  the  8  entries  specified  in  table  VII.  Draft 
conformance  level  for  interpreters  allows  black  and  white  to  be 
reversed  in  the  first  two  indices. 

In  table  VII,  replace  255  with  1.0,  and  add  a  note  after  the 
table:  "NOTE:  The  values  '1.0'  in  the  preceding  table  denote 

full  intensity  for  the  appropriate  component." 

Delete  the  last  sentence  of  3. 2. 8. 2. 

Add  a  new  3. 2. 6. 3  Implicit  Color  Table: 

The  default  Color  Table  is  undefined  in  FIPS  PUB  128.  It  is 
always  possible  to  specify  an  entire  default  Color  Table 
with  Metafile  Defaults  Replacement.  This  ESCAPE  element 
provides  a  shorthand  method  to  select  a  default  color  table 
from  a  small  set  of  predefined  tables,  and  provides  as  well 
a  method  to  specify  that  the  interpreter  shall  define  its 
own  color  table  according  to  available  resources.  This 
ESCAPE  is  allowed  in  the  Metafile  Descriptor.  If  used,  no 
COLOR  TABLE  elements  may  appear  in  the  metafile.  The  single 
integer  parameter  of  the  ESCAPE  has  the  following  meanings: 

0:  "none"  —  there  is  no  implicit  default  value  of  the 

color  table,  interpreters  may  associate  representations 
with  color  indexes  as  they  see  fit. 

1:  "cyclic"  —  the  interpreter  should  initialize  its 

color  table  to  contain 
0  -  white 
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1  -  black 

2  -  red 

3  -  green 

4  -  blue 

5  -  yellow 

6  -  magenta 

7  -  cyan 

8  -  black 

9  -  white 

10  through  255  -  cyclic  repetition  of  2-9. 

2;  "uniform”  —  the  interpreter  should  initialize  its 
color  table  to:  black  and  white  in  indexes  0  and  1. 

Beginning  at  index  2  ,  224  representations  that 

uniformly  sample  the  RGB  color  cube  as  follows: 

5  levels  of  red  evenly  spaced  from  none  to 
maximum; 

9  levels  of  green  evenly  spaced  from  none  to 
maximum; 

5  levels  of  blue  evenly  spaced  from  none  to 
maximum. 

The  color  cube  is  mapped  to  the  linear  array  by  varying 
the  red  dimension  most  rapidly,  then  the  green 

dimension,  then  the  blue  dimension.  Note  that  the 
225th  element  implied  by  this  sequence,  black,  is  not 
put  into  the  table.  Beginning  at  index  226  are  28 

levels  of  gray.  Index  226  is  1/32  (very  dark) . 
Succeeding  entries,  with  the  exceptions  described 
below,  are  1/32  lighter.  The  exceptions  are  0/32, 
8/32,  16/32,  24/32,  32/32,  which  may  be  found  in  the 

"color  cube"  section  of  the  table. 

The  default  value  of  the  parameter  is  1,  "cyclic". 

ESCAPE  IDENTIFIER:  -303 

ESCAPE  DATA  RECORD:  A  single  string  of  text  containing  the 
single  integer  parameter  of  this  escape  element.  The 

integer  is  encoded  as  "clear  text",  i.e.,  value  2  is  encoded 
as  the  string  comprised  of  (or  containing)  the  ASCII 

character  "2". 

Rewrite  the  last  section  of  3.2.8. 1:  "Conforming  generators 

shall  provide  to  applications  the  means  to  either  select  the 

implicit  color  table  for  a  metafile  or  to  ascertain  the  value 

that  will  be  used  in  the  metafile.  The  means  to  ascertain  the 

value  may  consist  of  either  a  software  inquiry  mechanism  or 
documentation  accompanying  the  system.  An  inquiry  mechanism  is 
the  preferred  method." 
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3.0  Deviations  between  TOP  and  CALS 

As  specified  in  the  order  for  this  project,  liaison  with  the 
experts  developing  and  maintaining  the  TOP  COM  Application 
Profile  has  been  maintained.  Changes  of  interest  to  both 
profiles  continued  to  be  negotiated  until  input  to  the  TOP  AP  was 
closed  and  the  final  version  printed  (see  Appendix  A)  .  Some 
significant  issues  were  raised  since  the  closure  of  TOP  to 
technical  change,  during  review  of  MIL-D-CGM  within  the  CALS 
industry  community  and  within  DoD. 

Prior  to  closure  of  input  to  the  TOP  AP,  a  number  of  differences 
exist  between  the  two  profiles  (and  are  recognized  in  the  TOP 
AP)  : 

1.  The  Metafile  Description  element  in  the  TOP  AP  contains 
the  substring  TOP/BASIC-1,  whereas  in  MIL-D-CGM  it 
contains  the  substring  MIL-D-CGM/BASIC-1 . 

2.  The  TOP  AP  allows  interpreters  to  use  only  the  Hershey 
fonts  for  rendering  pictures.  MIL-D-CGM  allows  the  use 
of  any  font  which  is  "metrically  identical”  to  a 
requested  Hershey  font. 

3.  MIL-D-CGM  has  added  a  number  of  additional  linetypes 
and  hatch  styles  for  engineering  applications. 

4.  MIL-D-CGM  has  specified  two  conformance  levels  for 
interpreters  (Publication  Level  and  Draft  Level) , 
whereas  the  TOP  AP  specified  only  one. 

Since  closure,  attempts  to  reconcile  review  comments  on  MIL-D-CGM 
have  lead  to  a  number  of  additional  differences  of  substance: 

a.  Since  CGM  Addendum  1  will  likely  impose  an  order  on  a 
few  of  the  Metafile  Descriptor  elements,  a  note  to  this 
effect  is  added  to  MIL-D-CGM  and  a  recommendation  that 
this  order  be  observed  (for  the  elements  Metafile 
Version,  Metafile  Element  List,  and  Metafile 
Description) . 

b.  In  MIL-D-CGM  the  behavior  of  the  Device  Viewport  escape 
has  been  clarified  and  brought  into  alignment  with  the 
specifications  of  ISO  CGI  (Computer  Graphics  Interface) 
and  the  ISO  CGM  Addendum  1.  It  is  not  clear  whether 
this  is  slightly  different  from  that  intended  in  TOP  or 
simply  a  more  precise  statement  of  the  requirement. 

c.  The  maximum  string  length  has  been  changed  in  MIL-D-CGM 

from  256  to  254.  256  was  somewhat  of  an  arbitrary 

choice,  and  is  just  slightly  longer  than  the  longest 
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string  expressible  in  a  short-format  binary  text  string 
(254)  . 

d.  The  Basic  values  of  Transparency  in  MIL-D-CGM  have  been 
limited  to  the  single  value  1  (on) .  The  effects  of 
this  element  in  CGM  itself  are  described  as  device 
dependent  for  the  value  0  (off) . 

e.  MIL-D-CGM  has  dropped  the  requirement  that  the  Metafile 
Descriptor  contain  the  Character  Set  List  element 
listing  (0,4/2)  and  (0,4/1).  The  vast  majority  of 
applications  will  simply  use  ASCII,  and  that  is  the 
default,  so  announcing  the  requirement  for  the  other 
set  makes  no  sense. 

f.  Significant  revisions  have  been  made  to  the  color 
functionality  in  MIL-D-CGM.  The  differences  with  TOP 
now  are: 

TOP  says  all  color  table  elements  must  appear 
before  the  first  graphical  primitives.  MIL-D-CGM 
now  says  that  they  just  must  appear  before  they 
are  used  by  a  primitive  or  attribute.  The  effect 
is  the  same  but  the  latter  specification  will  be 
somewhat  easier  for  applications  and  generators. 

-  There  is  no  requirement  for  color  index  definition 
in  the  metafile  in  the  TOP  AP.  MIL-D-CGM  now 
requires  that  either  all  indexes  which  are  used  in 
a  metafile  shall  be  defined,  or  none  shall  be 
defined.  The  case  of  having  some  indexes  which 
are  used  be  defined  and  some  not  defined  is 
prohibited. 

The  TOP  AP  defines  the  default  Color  Table  for 
interpreters  to  be  a  cyclic  repetition  of  the 
colors  Red,  Green,  Blue,  Yellow,  Magenta,  Cyan, 
Black,  White,  starting  at  index  2.  Indexes  0  and 
1  are  left  undefined.  In  the  default  case 
MIL-D-CGM  now  specifies  the  same  table  except  that 
index  0  is  defined  to  be  white  and  index  1  black. 

MIL-D-CGM  has  added  an  Escape  element.  Implicit 
Color  Table,  with  Escape  Indicator  -303.  This 
element  allow  a  generator  to  specify  how 
interpreters  are  to  initialize  their  color  tables. 
One  option  is  "none”,  which  means  the  interpreter 
is  to  use  its  native  color  capabilities  as  best  it 
can  and  initialize  its  color  table  accordingly. 
The  other  two  options  are  shorthands  for  selecting 
one  of  two  useful  initialization  schemes  \(em  the 
first  is  the  "cyclic"  scheme  (the  default  for  the 
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AP)  ,  and  the  second  is  a  uniform  sampling  of  the 
RGB  color  cube. 


IV.  SUMMARY  AND  CONCLUSIONS 

In  1987  this  project  produced  the  first  draft  of  the  CALS  CGM 
Application  Profile.  This  work  was  carried  out  in  close 
collaboration  with  the  TOP  graphics  experts,  and  in  consequence 
significant  changes  to  the  TOP  AP  were  made.  The  two  APs  were 
nearly  identical  in  areas  of  overlap.  Neither  profile  had  been 
subjected  to  "field  testing",  i.e.,  use  in  real  world 
applications  or  demonstrations  of  multi-vendor  systems 
integration. 

In  early  1988,  the  MIL-D-CGM  was  derived  from  the  CALS  AP  and 
incorporated  into  MIL-STD-1840A.  The  CGM  standard  and  the  CALS 
and  TOP  APs  received  significant  attention  and  use  in  a  number  of 
areas.  In  addition,  the  initial  drafts  of  both  AP  were  subject 
to  review  by  a  much  wider  community  during  1988  than  had  been  the 
case  in  1987.  Additional  real  world  experience  was  gained  in  the 
process  of  examining  and  handling  hundreds  of  CGMs  during  the 
production  of  the  first  test  set  for  CGM  interpreters. 
Significant  progress  was  made  in  standardization  of  CGM 
extensions  and  ^.n  Graphical  Registration  for  CGM  extension. 

In  consequence  of  these  activities  a  number  of  changes  have  been 
identified  for  the  CALS  AP  (MIL-D-CGM) .  Firstly,  there  are 
numerous  editorial  changes  and  corrections.  There  are,  in 
addition,  several  changes  which  are  mainly  clarification  but  do 
change  the  functionality  at  least  slightly  (clipping,  device 
viewport,  and  interpreter  conformance  levels) .  A  section  has 
been  added  to  document  those  errors  which  have  been  found  in  the 
CGM  standard  itself  (FIPS  PUB  128) .  Examples  of  the  engineering 
linetypes  and  hatch  styles  have  been  added. 

Next  there  are  a  number  of  minor  functional  changes:  the 
contents  of  the  text  bundle  table  are  adjusted  slightly;  maximum 
string  length  is  changed;  there  is  no  need  for  the  character  set 
list  element;  the  tables  of  additional  linetypes  and  hatch  styles 
are  modified  slightly;  the  use  of  the  device  dependent 
Transparency  element  is  restricted. 

One  of  the  biggest  problems  in  predictable  interchange  with  CGM 
has  been  the  use  of  indexed  color.  Neither  the  CALS  nor  the  TOP 
APs  solved  this.  In  fact  the  specifications  in  the  APs  turned 
out  to  actually  introduce  unpredictability  into  CGM  interchange. 
A  set  of  changes  has  been  recommended  to  fix  these  problems  and 
address  other  comments  received  during  MIL-D-CGM  review. 
Basically,  a  conforming  metafile  must  either  define  all  color 
indexes  that  are  used,  or  define  none  of  them;  and  a  new  escape 
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is  added  to  allow  a  shorthand  definition  of  the  implicit 
(default)  color  table  for  the  interpreter. 

A  handful  of  changes  are  recommended  to  MIL  STD  1840A.  That 
specification,  and  not  the  MIL-D-CGM,  should  handle  presentation 
of  metafiles  in  a  document  (e.g.,  by  reference  to  ISO  8613);  and 
it  should  handle  physical  data  formats  for  metafiles.  The  binary 
encoding  is  felt  to  be  adequate  for  interchange,  but  1840A  should 
recommend  that  delivered  CGM  software  systems  (generators  and 
interpreters)  have  Clear  Text  capability. 


V.  RECOMMENDATIONS 
1 . 0  Future  Work 

A  first  usable  version  of  the  CALS  AP  is  now  complete  and  has 
been  reviewed  see  Appendix  B) .  Over  the  next  year,  two  important 
activities  for  the  CALS  AP  should  be  pursued. 


2.0  Consolidation  with  TOP 

Because  of  different  production  schedules,  production  and  review 
processes,  and  editors  it  has  been  difficult  to  keep  the  TOP  and 
CAI^  profiles  in  substantial  alignment.  In  particular,  in  the 
last  part  of  the  1988  CALS  project  the  AP  was  reviewed  by  a  wider 
audience  than  had  formerly  done  so,  and  a  number  of  good  comments 
were  received.  Some  of  these  led  to  substantial  changes.  As  a 
result  the  two  profiles  have  now  diverged  somewhat. 

This  coordination  problem  will  continue  to  be  difficult.  In  1989 
CALS  should  pursue  with  TOP  the  possibility  of  merging  the  two 
profiles  into  a  single  one,  with  a  single  technical  editor,  and 
reviewing  that  single  profile  jointly  in  the  two  communities.  It: 
appears  from  initial  discussions  that  there  are  sufficiently 
similar  constituent  requirements  to  make  this  feasible. 


3.0  Further  Extensions  to  the  CALS  AP 

The  current  CALS  AP  has  begun  the  process  of  extending  the 
functionality  of  CGM.  Additional  Linetypes  and  Hatch  Styles,  as 
used  in  engineering,  have  been  added.  These  proposals  were 
submitted  (under  another  project)  to  the  Graphical  Registration 
process  and  have  undergone  at  least  two  rounds  of  review.  It  is 
expected  that  they  will  be  approved  in  substantially  their 
current  form,  and  are  therefore  stable  enough  to  include  in  the 
CALS  AP. 

There  are  currently  several  sources  of  additional  functionality 
of  interest  to  the  CALS  constituency.  The  additional 
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functionality  includes  such  areas  as  improved  text  and  font 
capabilities,  advanced  geometric  primitives  (splines,  conics, 
etc)  ,  and  global  segments  and  symbol  libraries.  It  is 
particularly  critical  that  improved  text  and  font  capabilities  be 
incorporated,  as  there  is  no  adequate  substitute  or  work-around 
available  in  CGM  or  the  APs  currently. 

The  sources  for  such  extensions,  and  the  time  frame  in  which  they 
are  expected  to  reach  substantial  stability,  are: 

o  The  functional  extensions  of  ISO  CGM  Addendum  1  (1 

year) ; 

o  Further  functional  extension  through  the  Graphical 
Registration  process  (1-1.5  years); 

o  The  functional  extensions  of  ISO  CGM  Addendum  3  (2-3 

years) . 

Addendum  3  is  being  specifically  formulated  for  the  needs  of 
technical  constituencies  such  as  CALS.  It  was  originally 

anticipated  that  the  functionality  therein  would  be  progressed 
and  stable  in  a  much  shorter  time  frame,  and  that  the  CALS  AP 
could  wait  for  such  stabilization  rather  than  endorsing 
variations  such  as  would  be  found  in  registration.  The  actual 
time  frame  is  now  too  long  to  wait. 

Consequently  in  1989  an  addendum  to  the  CALS  AP  should  be 
formulated  to  incorporate  that  functionality  which  is  needed  and 
is  then  available  from  Addendum  1  and  Graphical  Registration. 
During  1989  Addendum  1  should  reach  sufficient  stability  in  the 
ISO  pipeline  that  any  of  its  functionality  can  be  used  as 
appropriate.  Many  of  the  proposals  of  Graphical  Registration 
should  similarly  have  stabilized.  Although  the  content  of 
Addendum  3  may  differ  in  some  details  from  the  registration 
proposals,  the  basic  technology  covered  will  be  substantially  the 
same.  Having  the  technology  available  in  less  than  the  3-year 
time  frame  of  Addendum  3  now  appears  to  outweigh  the  disadvantage 
of  implementors  having  to  make  changes  of  detail  when  the  content 
of  Addendum  3  finally  becomes  standard. 
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T•c^nlcll  and  Offic*  Protocols 


6.2  Computer  Graphics  Metafile 

This  section  defines  the  TOP  CGM  Application  Profile  (AP)  for  the  Computer  Graohics 
Metafile  interchange  Format  Building  Block.  The  functional  description  and  binding 
rules  for  this  building  block  are  found  in  Chapter  2.  Section  2.4.10. 


6.2.t  CGM  Introduction 

The  TOP  CGM  AP  defines  the  conformance  characteristics  or  permissible  combinations 
for  all  possible  data  streams  that  are  specified  in  the  profile.  In  addition,  the  TOP  CGM 
AP  defines  additional  requirements  for  transmitting,  receiving,  interpreting  and 
handling  valid  CGM  data  streams.  The  definition  of  such  implementation  constraints  is 
usually  outside  the  scope  of  an  ISO  standard.  However,  such  APs  are  required  and 
necessary  to  insure  uniform  implementation  of  such  standards,  especially  where 
interchange  in  an  open  system  environment  is  concerned. 


6.2.2  CGM  Scope 

The  TOP  CGM  AP  defines  the  CGM  implementation  that  is  required  for  computer  graphics 
picture  information  interchange.  CGM  implementations  that  conform  to  this  AP  will  be 
able  to  be  integrated  into  other  application  processes  such  as  compound  document 
interchange.  This  AP  can,  in  the  future,  be  supplemented  by  additional  CGM  APs. 


6.2.3  Definitions 

APPLICATION  PROFILE  •  A  specification  that  defines  the  use  of  an  International  Standard. 

with  a  definition  of  all  possible  data  streams  that  conform  to  that  profile. 
An  AP  insures  interoperability  of  implementations  of  an  International 
Standard. 

BASIC  VALUE  -  The  subset  of  permissible  values  for  parameters  of  a  CGM  element  that 
are  mandatory  for  conformance  to  this  AP. 

CGM  Ml  •  A  CGM  metafile  input  workstation. 

CGM  MO  •  A  CGM  metafile  output  workstation. 

COMPOUND  DOCUMENT  -  A  digital  analog  of  a  document  containing  more  than  one 
component  objects  (such  as  character,  computer  graphics,  image  or 
facsimile  data). 

COMPOUND  DOCUMENT  INTERCHANGE  FORMAT  -  The  specification  for  a  mechanism  for 
storing  and  transferring  a  compound  document.  Refer  to  ISO  8613. 

COMPUTER  GRAPHICS  INTERFACE  (CGI)  -  The  specification  for  interface  techniques 
with  graphical  devices. 

COMPUTER  GRAPHICS  METAFILE  (CGM)  -  The  specification  for  a  mechanism  for  storing 
and  transferring  picture  description  information.  Refer  to  ISO  8632. 
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DATA  INTERFACE  -  The  communication  boundary  (i.e..  interface)  between  software 
modules  or  devices  comprising  one  or  more  operation  codes  and  data  (as 
contrasted  with  a  subroutine  call  interface). 

DEFAULT  VALUE  -  The  implicit  value  for  a  parameter  of  a  CGM  element.  For  example, 
default  Metafile  Name  in  Begin  Metafile  element  is  a  null  string. 

DEVICE  DRIVER  -  The  device-dependent  portion  of  a  graphics  system  which  supports  a 
physical  device.  The  device  driver  generates  device  class  specific  output. 

GRAPHICAL  KERNAL  SYSTEM  -  A  standardized  application  programmer’s  interface  to 
graphics  systems.  Refer  to  ISO  7942. 

METAFILE  •  Synonymous  with  CGM.  A  representation  for  the  storage  and  transfer  of 
graphical  data  and  control  information.  This  information  contains  a 
device-independent  description  of  one  or  more  pictures. 

METAFILE  GENERATOR  -  Synonymous  with  CGM  Generator.  The  software  or  hardware 
that  creates  a  picture  or  conveys  information  in  the  CGM  representation. 

METAFILE  INTERPRETER  -  Synonymous  with  CGM  Interpreter.  The  software  or 
hardware  that  reads  the  CGM  and  interprets  the  contents. 

PERMISSIBLE  VALUES  -  The  range  of  valid  values  for  a  parameter  of  a  CGM  element  ? 
specified  in  ISO  8632. 

VIRTUAL  DEVICE  -  An  idealized  computer  graphics  device  that  presents  a  set  of  graphics 
capabilities  to  graphics  software  of  systems  via  the  CGI. 

NOTE:  Refer  to  ISO  8632,  clause  3  and  ISO  7942.  clause  3,  for  further  definitions 

of  computer  graphics  terms. 


6.2.4  CGM  Architectural  Concepts 

The  CGM  IS  designed  to  be  usable  and  useful  to  a  wide  range  of  applications,  graphics 
systems,  and  devices  or  workstations.  The  CGM  is  graphics  system  independent,  as  weii 
as  device  independent.  The  CGM  is  created  by  a  CGM  Generator.  The  CGM  Generator 
resides  at  the  level  of  the  device  driver  and  is  invoked  by  the  application  callable  layer. 
The  CGM  Generator  can  be  used  to  record  device-independent  picture  descriptions, 
conceptually  in  parallel  with  the  presentation  of  images  on  actual  devices.  Figure  6.2- 1 
illustrates  the  TOP  Graphics  Reference  Model  for  creation  of  the  CGM. 
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File  Store 


Figure  6.2^1:  CGM  Generator  Reference  Model 


The  CGM  is  designed  to  be  interpreted  in  one  of  two  ways.  First,  the  CGM  can  be 
interpreted  by  a  special  application  program,  that  in  turn  invokes  a  device-independent 
graphics  system  to  render  the  CGM.  Second,  a  device-independent  graphics  system  may 
have  functions  that  can  be  invoked  by  an  application  to  get,  read,  and  interpret  metafile 
elements  using  the  facilities  of  a  CGM  metafile  input  workstation.  Figure  6.2-2 
illustrates  a  CGM  Generator  (primary)  Reference  Model.  Figure  6.2-3  illustrates  the 
CGM  Interpreter  (alternate)  Reference  Model. 

The  GKS  may  be  the  device  independent  graphics  system  that  is  used  in  figures  6.2-2  arc 
6.2-3.  GKS  (ISO  7942),  however,  does  not  specifically  refer  to  the  CGM  any  more  than 
it  does  to  another  specific  class  of  graphics  device. 
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Figure  6.2-2:  CGM  Interpreter  Reference  Model 


File  Store 


Figure  6.2-3:  Alternate  CGM  Interpreter  Reference  Model 
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6.2.5  CGM  Conformanca 

The  TOP  CGM  AP  specifies  conformance  in  terms  of  ’permissible  and  "basic"  values. 
Permissible  values  are  the  range  of  values  of  CGM  elements  as  specified  in  ISO  8632. 
Basic  values  are  a  subset  of  the  permissible  values  that  constitute  the  "basic  set".  For 
example,  permissible  values  of  LINE  TYPE  include  all  non-zero  integers,  while  basic 
values  include  the  standardized  enumerated  values  1  to  5. 

TOP  defines  a  conforming  "basic  metafile"  to  be  one  that  contains  no  elements  or 
parameter  values  outside  of  the  basic  set.  TOP  defines  a  conforming  "basic  interpreter' 
to  be  one  that  correctly  interprets  any  conforming  basic  metafile  and  may  have  more 
capability  as  well.  TOP  defines  a  conforming  "basic  generator*  as  one  that  produces  only 
conforming  basic  metafiles,  or  can  reliably  be  directed  to  function  in  a  mode  of 
producing  basic  metafiles. 

In  addition,  any  TOP  basic  interpreter  should  correctly  parse  and  pass  over  any  elements 
that  it  does  not  support  and  any  parameter  values  that  it  does  not  support. 

CGM  (ISO  8632)  defines  the  form  (syntax)  and  the  functional  behavior  (semantics)  of 
the  ordered  set  of  metafile  elements.  There  are  three  different  encodings  of  the  CGM  that 
have  been  standardized.  These  include  Clear  Text  Encoding,  Character  Encoding,  and 
Binary  Encoding.  This  AP  specifies  the  CGM  Binary  Encoding,  ISO  8632/3.  Future 
application  profiles  may  be  developed  for  the  other  encodings. 

For  interchange  of  CGM  files  on  a  TOP  network  the  binary  encoding  is  required. 


6.2.6  Metafile  Constraints 

The  basic  set  is  defined  by  the  limitations  on  permissible  values  below.  Where  an 
element  is  not  mentioned,  it  is  implied  that  the  basic  set  includes  all  values  permitted  m 
the  CGM. 

6.2.6. 1  Delimiter  Elements 

E'enient 
NO-OP 

Table  6.2-1:  Delimiter  Element  Constraints 


Basic  Value 

An  arbitrary  sequence  of  n  octets. 
n-0,1.2 . 32757 
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6. 2. 6. 2  Metafile  Descriptor  Elements 

glament  BaalC-Yaliig 


Metafile  Description 
Integer  Precision 
Real  Precision 

Index  Precision 
Color  Precision 
Color  Index  Precision 
Maximum  Color  Index 
Font  List 

Character  Set  List 
Character  Coding  Announcer 


(Note  1) 

1  6 

0,9.23  (floating  point) 

1.16.16  (fixed  point) 

1  6 

8.16 
8,16 
255 

(Note  4) 

0.4/2  (Note  2) 

1,4/1  (Note  3) 

0.1 


Note  1 :  Implementors  are  encouraged  to  use  the  Metafile  Description  element's 

string  to  include  a  brief  identification  of  their  company  or  product,  so 
that  interpreters  can  account  for  known  idiosyncrasies  of  generators.  The 
string  "TOP/BASIC- 1“  shall  be  included  within  the  Metafile  Description 
string  to  label  the  metafile  as  conforming  to  this  profile. 

Note  2:  The  character  set  is  ANS  X3.4.  7-bit  American  National  Standard  Code  for 

Information  Interchange  (7-bit  ASCII). 

Note  3;  The  chaiacter  set  is  ANS  X3. 134/2.  8-bit  American  National  Standards 
Standard  Code  for  Information  Interchange  (8-bit  ASCII).  This  is 
equivalent  to  ISO  8859/1,  Right-Hand  Part  of  Latin  Alphabet  Part  1. 

Note  4;  Four  simultaneous  fonts  are  supported.  The  font  names  are  selected  from 
the  basic  font  names  in  Table  6.2-8. 

I'aP/e  6.^-Z-  Metafile  Descriptor  Slement  Constraints 


6. 2. 6. 3  Picture  Descriptor  Elements 

Element  BaaiC-  YalUfl 

Scaling  Mode  (Note  1) 

Note  1 :  Implementors  should  use  care  in  specifying  the  value  of  the  metric 

scaling  factor  to  ensure  that  it  has  sufficient  significant  resolution  to 
specify  the  intended  accuracy. 

Table  6.2-3:  Picture  Descriptor  Element  Constraints 
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6. 2. 6. 4  Control  Elements 

giement  BaaiC-.Yalua 

VDC  Integer  Precision  16.32 

VDC  Real  Precision  0.9.23  {floating  point) 

1.16.16  (fixed  point) 

Table  6.2-4:  Control  Element  Constraints 


6. 2. 6. 5  Graphics  Primitive  Elements 

To  ensure  portability  and  predictable  results.  TOP  conforming  basic  metafiles  may  not 
contain  any  Generalized  Drawing  Primitive  (GDP)  elements. 


6. 2. 6. 6  Attribute  Elements 

Elftintint 

Line  Bundle  index 
Line  Type 

Marker  Bundle  Index 
Marker  Type 
Text  Bundle  index 
Text  Font  Index 
Character  Set  Index 
Alternate  Character  Set  Index 
Fill  Bundle  Index 
Hatch  Index 
Pattern  Index 
Edge  Bundle  Index 
Edge  Type 
Pattern  Table 


Color  Table 


Baste  Value 

1  -5 
1  -5 
1  -5 
1  -5 
1  -2 
1  -4 
1  -2 
1  -2 
1  -5 
1  -6 
1  -8 
1-5 
1  -5 

Pattern  Table  index.  1-8 

nx.  1-16 

ny.  1-16 

Starting  Color  Index.  0-255 


Table  6.2-5:  Attribute  Element  Constraints 


6. 2. 6. 7  Escape  Elements 

To  ensure  portability  and  predictable  results,  TOP  conforming  basic  metafiles  may 
contain  only  those  ESCAPE  elements  that  are  defined  in  Section  6.2.8.2  of  this  AP. 
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6. 2. 6. 8  External  Elements 

element  Basle  Value 

Message  Action  Required  Flag.  0 

Table  6.2-6:  External  Element  Constraints 


6.2.7  CGM  Defaults 

The  CGM  specifies  a  complete  set  of  defaults.  In  a  few  cases,  these  defaults  are  not 
appropriate  for  TOP  requirements.  However,  any  TOP  metafile  must  be  a  legal  CGM. 
This  includes  implicit  defaults  specified  in  ISO  8632/1,  clause  6,  and  ISO  8632/3. 
clause  8.  Therefore,  each  deviation  from  the  implicit  defaults  requires  that  the  affected 
element  either: 

1 .  Appear  in  the  Metafile  Defaults  Replacement  element,  or 

2 .  Be  explicitly  specified  for  its  value  to  be  applicable. 

Each  TOP  conforming  basic  metafile  shall  contain  in  the  Metafile  Descriptor  a  Metafile 
Defaults  Replacement  element  that  includes  at  a  minimum: 

1 .  Text  Precision  element,  where  precision  is  set  to  2  (stroke). 

Each  TOP  conforming  basic  metafile  shall  also  contain  in  the  Metafile  Descriptor,  the 
following  elements: 

1 .  Maximum  Color  Index  element,  where  the  maximum  color  index  is 
set  to  255. 

2.  Character  Set  List  element,  where  the  first  two  character  set 
indices  are  set  to  (0,4/2)  and  (1.4/1). 

It  is  not  apparent  in  the  CGM  standard  what  the  default  value  for  the  precision  of  the 
floating  point  real  parameter  of  Scaling  Mode  should  be.  TOP  conforming  generators  and 
interpreters  shall  assume  that  the  real  precision  for  this  parameter  is  (0,9,23). 

Color  table  defaults  for  color  indices  0  and  i  are  explicitly  defined  in  the  CGM  standard 
as  corresponding  to  the  nominal  background  and  nominal  foreground  colors, 
respectively. 

TOP  conforming  CGM  interpreters  will  initialize  their  color  table  with  the  starting 
color  table  index  set  to  2,  and  the  list  of  direct  color  values  for  the  remaining  254 
entries  a  repetition  of  the  following  eight  values: 
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Index 

Valuaa 

Maanlna 

2 

(255,  0.  0) 

Red 

3 

(0.  255.  0) 

Green 

4 

(0.  0.  255) 

Blue 

5 

(255,  255,  C) 

Yellow 

6 

(255,  0.  255) 

Magenta 

7 

(0.  255.  255) 

Cyan 

8 

(0.  0.  0) 

Black 

9 

(255,  255,  255) 

White 

Table  6.2-7:  Default  Color  Table 


6.2.8  CGM  Related  Private  Use  of  Elements 


6. 2. 8.1  Fonts 

The  fonts  in  Table  6.2-8  are  public  domain  fonts,  available  from  the  U.S.  National 
Bureau  of  Standards  (NBS)  [CGMRefS].  All  of  these  fonts  are  considered  to  be  basic 
capabilities  of  a  TOP  conforming  basic  metafile.  Any  of  these  fonts  may  appear  in  the 
Font  List  element  in  a  CGM  that  conforms  to  this  AP.  The  font  names  are  specified  in  a 
manner  compatible  with  ISO  9541,  Font  and  Character  Information  Interchange 
[CGMRefll].  The  font  name  (Font  Identifier  for  Base  Font)  is  a  concatenated  string  of 
the  Universal  Font  Name  and  a  User  Readable  Font  Name.  The  Universal  Font  Name  for 
these  fonts  is  assumed  to  be  "NBS*.  pending  the  registration  of  the  National  Bureau  of 
Standards  with  an  Organization  Name.  The  User  Readable  Font  Name  is  the  concatenated 
string  "HERSHEY;",  to  designate  one  of  the  Hershey  fonts,  and  ’name  string",  to  designate 
the  particular  typeface. 

Note:  The  Hersey  "fonts*  are  really  combined  specifications  of  font  and  character 

set,  in  the  terminology  of  standards.  So  support  of  the  Hersey  "fonts’  really 
implies  support  of  a  number  of  fonts  and  character  sets. 


1.  NBS  HERSHEYCARTOGRAPHIC  ROMAN 

2.  NBSHERSHEYCARTOGRAPHC.GREEK 

3.  NBS  HERSHEYSIMPLEX  ROMAN 

4 .  NBS  HERSHEYrSiMPLEX  GREEK 

5.  NBS  HERSHEY:SIMPLEX  SCRIPT 

6 .  NBS  HERSHEYOOMPLEX  ROMAN 

7 .  NBS  HERSHEYOOMPLEX  GREEK 

8 .  NBS  HERSHEYCOMPLEX  SCRIPT 

9.  NBSHERSHEYCOMPLEX  ITAUC 

1  0 .  NBS  HERSHEYOOMPLEX  CYRILUC 

11.  NBS  HERSHEY-.DUPLEX_RC>MN 

1  2 .  NBS  HERSHEY;TRIPLEX_ROMAN 

1  3 .  NBS  HERSHEY:TRIPLEXJTAUC 

14.  NBS  HERSHEY<30THIC  GERMAN 

15.  NBS  HERSHEYGOTHIC  ENGUSH 

16.  NBS  HERSHEYGOTHICJTAUAN 


TOP  V3.0  in  («tract  •  adiwd) 


28 


3/24  aa 


T«c^nical  and  Omc*  Protocoit 


There  are  four  parameters.  Invalid  parameters  will  result 
in  this  Escape  element  being  ignored. 


P1;  First  corner  x-coordinate.  Real  fraction  of  the  default 
Device  Viewport,  in  the  range  [0.0,  l.Ol. 

P2:  First  corner  y-coordinate.  Real  fraction  of  the  default 
Device  Viewport,  in  the  range  (0.0.  l-O). 

P3:  Second  corner  x-coordinate.  Real  fraction  of  the 
default  Device  Viewport,  in  the  range  [0.0,  1.0). 

P4:  Second  corner  y-coordinate.  Real  fraction  of  the 
default  Device  Viewport,  in  the  range  [0.0,  i.O]. 

For  example,  a  Device  Viewport  equal  to  the  upper  right  quarter  of  the  default  Device 
Viewport  would  be  coded  with  the  following  Escape  element: 


Escape  Identifier:  -3  02 

Escape  Data  Record:  *.5,.5,1  ..i 

OR 


Escape  Identifier:  - 3 02 

Escape  Data  Record:  *0.50  0.50  1.0  1.0" 


A  Device  Viewport  equal  in  width  to  the  left  one  tenth  of  the  default  Device  Viewport  and 
equal  in  height  to  the  default  Device  Viewport  would  be  ceded  with  the  following  Escape 
element: 


Escape  Identifier:  -3  02 

Escape  Data  Record:  ’0.,  0..  .1.  i.* 


6.2.9  COM  Implementation  Dependencies 

This  section  describes  the  implementation  dependencies  and  environmental  constraints 
for  this  AP.  Specifying  the  nominal  values  for  such  implementation  practices,  defaults, 
and  options  will  facilitate  uniform  generation  and  interpretation  of  the  CGM. 


6. 2. 9.1  General  Guidelines  for  CGM  Elements 

Unless  otherwise  noted  in  this  AP,  all  of  the  guidelines  of  ISO  8632,  Annex  D.  shall  be 
adhered  to  by  TOP  CGM  generators  and  interpreters.  In  particular,  the  interpreter 
minimum  capabilities  of  ISO  8632,  Annex  0.5,  plus  the  interpreter  functions  defined  m 
Section  6.2.6,  should  be  the  minimum  supported  capabilities. 

Name:  Metafile  Defaults  Replacement 

Description:  The  Metafile  Defaults  Replacement  element  shall  not  be 

partitioned.  In  addition,  no  part  of  the  element  will  be  partitioned. 
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Note:  Multiple  occurrences  of  the  Metafile  Defaults  Replacement 

element  are  allowed  by  the  CGM  standard  and  this  AP. 


Name:  Restricted  Text 

Description:  Minimal  capability  of  a  basic  conforming  TOP  interpreter  shall 

render  the  complete  restricted  text  string  (i.e..  Append  Text 
elements  permitted),  scaled  isotropically  (i.e.,  specified  aspect 
ratio  for  the  text  is  not  distorted),  such  that  the  text  string  fits 
into  the  Text  Extent  parallelogram. 


Name:  Color  Table 

Description:  The  Color  Table  element  has  an  unspecified  effect  when  it  appears 

in  a  picture,  subsequent  to  any  graphical  primitive  elements.  The 
Color  Table  element  should  appear  prior  to  any  graphical 
primitive  elements  to  insure  that  interpreting  systems  without 
dynamic  color  update  capabilities  can  render  the  intended  effect. 


6. 2. 9. 2  Implementation  Guidelines  for  Generators  and  Interpreters 
This  section  is  meant  to  augment  ISO  seSZi'l,  Annex  0.5  and  ISO  8632/3,  clause  8. 


6. 2. 9. 2.1  Minimum  Data  Structure  Support 

Name:  Maximum  Color  Array  Dimension 

Description:  The  basic  value  for  the  number  of  color  values  that  can  appear  in  a 

color  array  or  color  list  parameter.  CELL  ARRAY  has  a  color  list 
parameter.  PATTERN  TABLE  has  a  color  array  parameter.  COLOR 
TABLE  has  a  color  list  parameter. 

Basic  Value:  1048576  for  CELL  ARRAY  (i.e.,  one  1024  x  1024  image), 

2048  for  PATTERN  TABLE  (i.e.,  eight  16x16  patterns), 

256  for  COLOR  TABLE  (i.e..  entries  0-255) 


Name:  Maximum  Point  Array  Length 

Description:  The  basic  value  for  the  number  of  points  that  can  appear  m 

parameters  for  metafile  elements. 

Basic  Value:  1024 


Name:  Maximum  String  Length 

Description:  The  basic  value  for  the  length  of  an  individual  string  of  characters. 

Basie  Value:  256  for  all  string  parameters  except  data  records. 


3/24/88 


30 


TOP  V3.0  IR  (Mtraa  -  aflitaoi 


Technical  and  Ottics  Protocoia 


32767  for  data  records 


Name: 

Description: 

Basie  Value: 


Bundle  Table 

The  bundle  representations  are  not  settable  in  the  current  version 
of  the  CGM.  This  implementation  dependency  detracts  from  the 
open  interchange  of  the  CGM.  The  following  default  bundle  table 
values  will  permit  a  picture  to  be  uniformly  rendered  by  ail 
conforming  basic  TOP  interpreters. 

Refer  to  Table  6.2-9 


Hiindifl  Type  Bundle  Index 

Bundle 

Representation  1  2  3 


Line  Bundle 

Line  Type 

Solid 

Dash 

Line  Width 

1 

1 

Line  Color 

1 

1 

Marker  Bundle 

Marker  Type 

Dot 

Plus 

Marker  Size 

1 

1 

Marker  Color 

1 

1 

Text  Bundle 

Font  Index 

1 

1 

Text  Precision 

Stroke 

Stroke 

Character 

1 

0.5 

Expansion  Factor 
Character 

0 

0 

Spacing 

Text  Color 

1 

1 

Fill  Area  Bundle 
Interior  Style 

Hatch 

Hatch 

Fill  Color 

1 

1 

Hatch  Index 

1 

2 

Pattern  index 

1 

1 

Dot  Dash-dot  Dash-dot-dot 


1  1  1 

1  1  1 

Asterisk  Circle  Cross 
t  t  1 

1  1  1 


Hatch 

Hatch 

Hatch 

1 

1 

1 

3 

4 

5 

1 

1 

1 

Edge  Bundle 
Edge  Type 
Edge  Width 
Edge  Color 


Solid  Dash  Dot  Dash-dot  Dash-dot-dot 

11111 
11111 

Table  6.2-9:  Basic  Bundle  Table 


TOP  V3.0  IR  (•*»!«  ■  aditad) 


31 


3/24/88 


Tschnical  and  Offica  Protocols 


6. 2. 9. 2. 2  CGM  Transfer  Format 

Operating  system  dependencies  for  file  formats  can  often  be  more  of  a  burden  on 
interoperability  than  differences  in  interchange  formats.  To  ensure  CGM 
interoperability,  some  conventions  for  file  formats  are  required. 

The  file  containing  the  CGM  should  be  formatted  into  fixed  length  80  octet  records,  if  the 
record  length  is  optionally  less  than  80  octets,  even  octet  records  are  required. 

Note:  When  the  files  are  being  transferred  on  magnetic  tape,  80  octet  records 

should  be  formatted  into  blocks  of  800  octets. 


6.2.10  CGM  Error  Processing 

A  TOP  conforming  interpreter  should  gracefully  recover  from  any  exception  condition. 
If  there  is  something  which  is  not  processable  by  the  interpreter,  processing  of  the 
metafile  should  continue  with  the  metafile  element  following  that  which  caused  the 
exception,  if  possible.  Exact  details  for  exception  handling  are  outside  the  scope  of  this 
recommendation. 


6.2.11  CGM  Conformance  Testing 

Conformance  testing  recommendations  for  the  conforming  TOP  basic  metafile  will  be 
addressed  by  subsequent  releases  of  this  recommendation. 


6.2.12  CGM  References 

These  references  relate  to  documents  applicable  to  this  specification. 

CGMRefI  ANS  X3.4  -  1986.  7-bit  American  National  Standard  Code  for 

Information  Interchange 

CGMRef2  ANS  X3.41  -  1974.  American  National  Standard  Code  Extension 

Techniques  for  Use  With  the  7-bit  Coded  Character  Set  of  American 
National  Standard  Code  for  Information  Interchange 

CGMRef3  ANS  X3. 134/1,  American  National  Standard  Code  for  8-bit  ASCII 

Structure 

CGMRett  ANS  X3. 134/2.  American  National  Standard  Code  for  7-bit  and  8-bit 
ASCII  Supplemental  Multilingual  Graphic  Character  Set 

CGMReS  NBS  Special  Publication  424  -  April  1976.  Hershey  Fonts 

CGMRefS  ISO  8613.  Information  Processing  •  Text  and  Office  Systems  -  Office 
Document  Architecture  and  Interchange  Format  (ODA/ODIF) 

CGMRef7  ISO  8632/1.  Information  Processing  Systems  -  Computer  Graphics 
Metafile  (CGM)  for  the  Storage  and  Transfer  of  Picture  Description 
Information  -  Part  1 :  Functional  Specification 
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CGMRefS 

ISO  8632/2.  Information  Processing  Systems  ■  Computer  Graphics 
Metafile  (CGM)  for  the  Storage  and  Transfer  of  Picture  Description 
Information  -  Part  2;  Character  Encoding 

CGMRefS 

ISO  8632/3.  Information  Processing  Systems  -  Computer  Graphics 
Metafile  (CGM)  for  the  Storage  and  Transfer  of  Picture  Description 
Information  -  Part  3;  Binary  Encoding 

CGMReflO 

ISO  8632/4.  Information  Processing  Systems  -  Computer  Graphics 
Metafile  (CGM)  for  the  Storage  and  Transfer  of  Picture  Description 
Information  -  Part  4;  Clear  Text  Encoding 

CGMRef1 1 

ISO  9541,  Information  Processing  Systems  -  Font  and  Character 
Information  Interchange 

CGMRefia 

ISO  DIS  8859/1.  Information  Processing  -  8-bit  Single  Byte  Coded 
Graphical  Character  Sets  -  Part  1 ;  Latin  Alphabet  Part  1 

CGMRef13 

ISO  7942,  Information  Processing  Systems  -  Computer  Graphics  - 
Graphical  Kernel  System  (GKS)  Functional  Description 

CGMRefU 

ISO  DIS  8805,  Information  Processing  Systems  -  Computer  Graphics  - 
Graphical  Kernel  System  for  Three  Dimensions  (GKS-3D)  Functional 
Description 

CGMRedS 

ISO  DP  9592.  Information  Processing  Systems  •  Computer  Graphics  - 
Programmers  Hierarchical  Interactive  Graphics  System  (PHIQS) 

CGMRefie 

ISO  TC97/SC21  Nil 79.  Information  Processing  Systems  -  Computer 
Graphics  •  Interfacing  Techniques  for  Dialogues  with  Graphical  Devices 
(CGI) 

6.2.1 3 

The  Use  of  OSI  Data  Transfer  Services 

To  transfer  a  CGM  file  between  two  TOP  End  Systems,  the  services  provided  either  by 
FTAM  or  by  MHS  can  be  used.  Remote  access  to  pan  of  a  CGM  file  is  not  addressed  at  this 
time. 

Using  FTAM  to  transfer  CGM  files: 

One  should  specify  the  CGM  file  Document  Type  entry  number  as  FTAM-3, 
Document-Type-Name  as  ’{ISO  standard  8571  document-type  (5) 
unstructured-binary  (3)}*  for  Contents-Type-Attribute  or  Contents- 
Type-List.  The  contents  of  the  CGM  tile  should  be  mapped  onto  a  sequence 
of  octet  strings.  The  boundary  of  the  octet  strings  has  no  significant 
meaning. 

Note:  As  there  is  no  standard  defined  document  type  at  this  time  for  a  CGM  type  file. 

the  presentation  layer  facilities  can  not  be  fully  used  and  it  is  left  up  to  the 
user  or  application  programs  that  remotely  access  files  using  FTAM  to  know 
that  a  given  file  contains  CGM  formatted  information. 
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Using  MHS  to  transfer  COM  files: 

One  should  specify  the  Body  as  USABody Parts  BodyPartNumber  '1'.  and 
the  contents  of  the  CGM  file  is  mapped  in  the  body  of  an  IMP  as  a  sequence 
of  octet  strings.  The  boundary  of  the  octet  strings  has  no  particular 
semantics. 


3/2«/83 
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APPENDIX  B 

FINAL  TEXT  OF  MIL-D-28003 
MILITARY  SPECIFICATION 

DIGITAL  REPRESENTATION  FOR  COMMUNICATION 
OF  ILLUSTRATION  DATA: 

CGM  APPLICATION  PROFILE 

(As  of  November  18,  1988) 
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MIL-D-28003 


MILITARY  SPECIFICATION 

DIGITAL  REPRESENTATION  FOR  COMMUNICATION  OF  ILLUSTRATION  DATA: 

CGM  APPLICATION  PROFILE 


NOTE:  This  draft,  dated  18  November  1988,  prepared 
by  the  OSD  CALS  Office  has  not  been  approved  and 
is  subject  to  modification. 

DO  NOT  USE  PRIOR  TO  APPROVAL.  (Project  ILSS-0034) 


1 .  SCOPE 

1.1  Scope.  This  military  specification  establishes  the 
requirements  to  be  met  when  2-dimensional  picture  description  or 
illustration  data  that  is  predominantly  vector  is  delivered  in 
the  digital  format  of  the  Computer  Graphics  Metafile  (CGM) 
specified  by  its  Federal  Information  Processing  Standard,  FI 
PUB  128. 


- 1 

Beneficial  comments  (recommendations,  additions,  ! 
deletions)  and  any  pertinent  data  which  may  be 
used  in  improving  this  document  shall  be  addressed 
to:  Director,  CALS  Policy  Office,  DASD(S)CALS 

Pentagon,  Room  2B322,  Washington,  DC  20301,  by 
using  the  self  addressed  Standardization  Document 
approval  Proposal  (DD  Form  1426)  appearing  at  the 
end  of  this  document  or  by  letter. 


AMSC  N/A  AREA  ILFS 

DISTRIBUTION  STATEMENT  A.  Approved  for  public  release; 
distribution  is  unlimited. 
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1.2  Classification.  This  specification  establishes  the 
requirements  for  the  communication  or  interchange  of  illustration 
data  in  digital  format  for  use  in  technical  illustrations  and 
publications.  The  CGM  Application  Profile  (AP)  defined  by  this 
specification  consists  of  three  parts;  the  metafile,  the 
generator,  and  the  interpreter.  There  shall  be  only  one  level 
for  the  metafile  and  generator,  and  they  shall  be  called 
conforming  basic  metafile  and  conforming  basic  generator, 
respectively.  The  interpreter  shall  be  one  of  the  following  two 
levels  as  specified  by  the  contract  or  purchase  order: 

Level  1  -  Publication  Level 

Level  2  -  Draft  Level 

Publication  Level  shall  be  mandatory  for  final  document 
production.  Draft  Level  defines  a  level  that  is  suitable  for 
working  when  documents  are  in  development  or  draft  stage.  Draft 
Level  shall  be  used  for  all  docximents  except  those  for  final 
document  production.  Additional  classes  of  conforming  basic 
metafiles  are  expected  to  be  added  in  future  versions  of  this 
specification  as  soon  as  technical  work  codifies  their 
requirements  and  validates  fitness  for  use. 
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2 .  APPLICABLE  DOCDMENTS 

2.1  Government  documents. 

2.1.1  Specifications  and  standards.  The  following  standards 
form  a  part  of  this  document  to  the  extent  specified  herein. 
Unless  otherwise  specified,  the  issues  of  these  documents  are 
those  listed  in  the  issue  of  the  Department  of  Defense  Index  of 
Specifications  and  Standards  (DODISS)  and  supplements  thereto, 
cited  in  the  solicitation. 

STANDARDS 

FEDERAL 

FIPS  PUB  128  -  Computer  Graphics  Metafile  (CGM) 

Note:  FIPS  PUB  128  adopts  ANSI  X3.122  as  a  Federal 

Information  Processing  Standard. 

(Copies  of  the  referenced  Federal  Information 
Processing  Standards  (FIPS)  are  available  to  Department 
of  Defense  activities  from  the  Commanding  Officer, 
Naval  Publications  and  Forms  Center,  5801  Tabor  Avenue, 
Philadelphia,  PA  19120-5099.  Others  must  request 
copies  of  FIPS  from  the  National  Technical  Information 
Service,  5285  Port  Royal  Road,  Springfield,  VA  22161.) 


MILITARY 


MIL-STD-1840  -  Automated  Interchange  of  Techn;:’. . 

Information 

(Copies  of  the  referenced  military  standard  ;  ro 
available  from  the  Department  of  Defense  Single  Stzj-: 
Point,  Commanding  Officer,  Naval  Publications  and  For-s 
Center,  5801  Tabor  Avenue,  Philadelphia,  PA  19120.) 

2.1.2  Other  Government  dr>gumgnt-.«^ .  The  following  error 

Government  document  forms  a  part  of  this  document  to  the  extorr 
specified  herein.  Unless  otherwise  specified,  the  issue  is  rr  >t 
cited  in  the  solicitation. 

NATIONAL  BUREAU  OF  STANDARDS 

NBS  SP  424  -  Contributions  to  Computer  Typesett.:  j 
Techniques:  Tables  of  Coordinates  :  r 
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Hershey's  Repertoire  of  Oxidental  Type 
Fonts  and  Graphic  Symbols,  NBS  Special 
Publication  424,  April  1976. 

(Application  for  copies  shall  be  addressed  to  the 
National  Technical  Information  Service,  5285  Port  Royal 
Road,  Springfield,  VA  22161.) 

2.2  Non-Govemment  publications.  The  following  documents  form  a 
part  of  this  document  to  the  extent  specified  herein.  Unless 
otherwise  specified,  the  issues  of  the  documents  which  are  DoD 
adopted  are  those  listed  in  the  issue  of  the  DODISS  cited  in  the 
solicits  ".ion.  Unless  otherwise  specified,  the  issues  of 
documents  not  listed  in  the  DODISS  are  the  issues  of  the 
documents  cited  in  the  solicitation  (see  6.2) . 

NATIONAL  STANDARDS 

ANSI  X3.4  -  7-bit  American  National  Standard  Code  for 

Information  Interchange  (7-bit  ASCII) 

ANSI  X3. 134/2  -  8-bit  American  National  Standards  Code  for 
Information  Interchange  (8-bit  ASCII) 

(Application  for  copies  shall  be  addressed  to:  American 
National  Standards  Institute,  Inc.,  1430  Broadway,  New 
York,  NY  10018) . 

(Nongovernment  standards  and  other  publications  are 
normally  available  from  the  organizations  which  prepare 
or  which  distribute  the  documents.  These  documents 
also  may  be  available  in  or  through  libraries  or  other 
informational  services.) 

2.3  Order  of  precedence.  In  the  event  of  a  conflict  between  the 
text  of  this  specification  and  the  references  cited  herein,  the 
text  of  this  specification  shall  take  precedence.  Nothing  in 
this  specification,  however,  shall  supersede  applicable  laws  and 
regulations  unless  a  specific  exemption  has  been  obtained. 
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3 .  REQUIREMENTS 

3.1  General  reouireaents.  This  specification  defines 
conformance  of  a  CGM  metafile  in  terms  of  "permissible”  and 
"basic"  values.  Permissible  values  are  the  range  of  values  of 
CGM  elements  as  specified  in  FIPS  PUB  128.  Basic  values  are  a 
sxibset  of  the  permissible  values  and  they  constitute  the  "Basic 
Set."  For  example,  permissible  values  of  MARKER  TYPE  include  all 
non-zero  integers,  while  basic  values  are  limited  to  the  specific 
values  1  to  5.  A  conforming  basic  metafile  shall  contain  no 
elements  or  parameters  outside  of  the  Basic  Set.  The  CGM  AP 
which  corresponds  to  the  illustration  data  to  be  communicated 
shall  be  in  the  form  of  one  or  more  conforming  basic  metafiles. 

3.1.1  Conforming  basic  generator.  A  conforming  basic  generator 
shall  be  defined  to  be  one  that  produces  only  conforming  basic 
metafiles  (or  can  be  reliably  commanded  to  function  in  that 
mode) ,  and  additionally  conforms  to  any  additional  generator 
requirements  as  explained  in  the  subsections  below. 

3.1.2  Conforming  basic  interpreter.  A  conforming  basic 
interpreter  shall  be  defined  to  be  one  that  at  least  correctly 
interprets  any  conforming  basic  metafile,  and  conforms  to  any 
additional  interpreter  requirements  as  explained  in  the 
subsections  below.  In  addition,  any  conforming  basic  interpreter 
shall  be  able  to  parse  and  skip  any  elements  that  it  does  not 
understand  or  support,  and  any  parameter  values  that  it  does  not 
support.  For  interpreters,  there  shall  be  two  levels  of 
conformance  for  judging  what  comprises  "correct"  interpretation 
of  a  metafile: 

Level  1  -  Publication  Level;  All  of  the  specifications  of  ""S 
PUB  128  and  of  this  CGM  AP  shall  be  accurately  implemented.  r'n.o 
includes  the  guidelines  of  FIPS  PUB  128  annex  D.2  and  D.5,  i 
the  recommendations  for  the  treatment  of  indeterm i n i o e 
specifications  of  circular  and  elliptical  primitives  in  FIPS  r'  3 
128  annex  D.4.5.  The  results  shall  be  completely  predict lol -5 
across  implementations  conforming  at  this  level;  that  .o, 
suitable  for  publication  as  the  name  implies. 

Level  2  -  Draft  Level:  The  guidelines  of  FIPS  PUB  128  annex  3.: 

(degeneracies)  and  D.3  (mapping  color  to  black-and-white)  sr.  i  l  l 
be  implemented.  The  recommendations  for  the  treatment 
indeterminate  specifications  of  circular  and  ellipti.-i. 
primitives  in  D.4.5  shall  be  followed.  The  capabilities  of 
D.5  of  FIPS  PUB  128  and  of  the  Basic  set  as  defined  in  tn 
specification  shall  be  present;  however,  the  folic:..--: 
interpreter  fallback  actions  of  D.4  may  be  taken: 
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AUXILIARY  COLOR 
APPEND  TEXT 
RESTRICTED  TEXT 
CELL  ARRAY 
LINE  WIDTH 
EDGE  WIDTH 
PATTERN  SIZE 


CHARACTER  SPACING 
CHARACTER  HEIGHT 
CHARACTER  ORIENTATION 
CHARACTER  SET  INDEX 
MARKER  SIZE 
TEXT  PRECISION 
CHARACTER  EXPANSION  FACTOR 


For  LINE  TYPE  and  HATCH  INDEX,  the  interpreter  shall  have  the 
capabilities  of  D.5  of  FIPS  PUB  128.  However,  the  interpreter 
may  take  fallback  actions  for  the  additional  linetypes  of  Table 
IV  and  hatch  styles  of  Table  V  below. 

3.1.3  T^imits  on  parameter  data.  A  conforming  basic  metafile 
shall  not  contain  scalar  values  of  parameter  data  outside  the 
ranges  specified  by  this  specification. 

3.1.4  Encoding  f ormat .  A  conforming  basic  metafile  shall  use 
only  the  CGM  Binary  Encoding,  as  defined  in  FIPS  °UB  128,  part  3. 
[NOTE:  Future  CGM  application  profiles  may  be  developed  (or  this 
profile  extended)  for  the  character  (FIPS  PUB  128,  part  2)  or 
clear  text  (FIPS  PUB  128,  part  4)  encodings  of  CGM.] 


3.1.5  Physical  file  structure.  All  basic  metafiles  conforming 
to  this  specification  shall  consist  of  80-octet  records.  when 
files  are  being  transmitted  on  magnetic  tape,  the  80-octet 
logical  records  shall  be  blocked  into  800-octet  physical  records. 

3.1.6  Errors  in  FIPS  PUB  128.  A  number  of  editorial  errors  have 
been  found  to  exist  in  the  published  version  of  ANSI  X3.122.  In 
order  to  prevent  errors  in  the  use  of  FIPS  PUB  128  within  this 
specification,  the  following  changes  to  ANSI  X3.122  shall  apply; 


Part  1,  p.  100,  the  last  item  on  the  page:  "1"  should  te 

"O"  and  "foreground”  should  be  "background”. 


Part  3,  p.l7,  item  11:  the  fraction  numerator  which  .s 

”pnx”  should  be  ”pnx-l”. 


Part  3,  p.26,  VDC  REAL  PRECISION:  ”31”  should  be 

Part  1,  clause  5.2.1  (p.  43),  clause  5.3.12  (p.  49),  ^r.i 

clause  6  (p.  100):  To  make  clear  and  remove  contradictory 

statements  in  these  clauses — Metafile  Descriptor  eler.ert:; 
shall  not  return  to  default  at  Begin  Picture,  and  they  sh i . . 
not  be  included  in  the  Metafile  Defaults  Replacement. 

Part  1,  p.l06,  the  expansion  of  "<metafile  contents>":  'r.:; 
”1”  symbols  should  be  deleted. 
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3.2  Specific  requirements.  The  following  subsections  define  the 
specific  requirements  for  a  conforming  CGM  AP.  An  application 
profile  shall  use  the  specified  element  types  of  FIPS  PUB  128 
with  the  constraints  as  specified  below. 

3.2.1  Metafile  constraints.  The  Basic  Set  shall  be  defined  by 
the  limitations  on  Basic  Values  noted  below.  Where  an  element  is 
not  mentioned,  it  is  implied  that  the  Basic  Set  shall  include  all 
values  permitted  in  FIPS  PUB  128. 

3.2. 1.1  Delimiter  elements.  The  only  constraint  on  delimiter 
elements  shall  be  for  no-op,  and  the  basic  values  allowed  shall 
be  an  arbitrary  sequence  of  n  octets,  i^O.. 32767. 

3. 2. 1.2  Metafile  descriptor  elements.  The  metafile  descriptor 
element  constraints  shall  be  as  specified  in  table  I. 


TABLE  I .  Metafile  descriptor  element  constraints 


Element 

Basic  Values 

Metafile  Description 

(Note  1) 

Integer  Precision 

16 

Real  Precision 

(1,16,16)  (fixed) 

(0,9,23) 

(floating  point) 

Index  Precision 

16 

Colour  Precision 

8,  16 

Colour  Index  Precision 

8,  16 

Font  List 

(Note  2) 

Character  Set  List 

(0,4/2) 

(Note  3) 

(1,4/1) 

(Note  4) 

Character  Coding  Announcer 

0  (Basic 

7-bit) 

1  (Basic 

3-bit) 

Note  1:  The  Metafile  Description  element's  string;  a)  shall 

include  a  substring  briefly  identifying  company  or  product,  so 
that  interpreters  can  account  for  known  idiosyncrasies  of 
generators;  b)  =hall  contain  the  substring  "MIL-D-28003/BASIC-l" . 

Note  2:  Four  simultaneous  fonts  are  supported.  The  font  names 
are  selected  from  the  basic  font  names  in  3.2.5. 

Note  3;  The  character  set  is  ANSI  X3.4,  7-bit  American  Nacional 
Standard  Code  for  Information  Interchange  (7-bit  ASCII) . 

Note  4:  The  character  set  is  ANSI  X3. 134/2,  8-bit  American 
National  Standards  Code  for  Information  Interchange  (3 -bit 
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ASCII) .  [Note:  This  is  equivalent  to  ISO  8859/1,  Right-Hand  Part 
of  Latin  Alphabet  Number  1.] 

3.2. 1.3  Picture  descriptor  elements.  Note  that  the  scale-factor 
parameter  of  SCALING  MODE  is  always  a  floating  point  number,  even 
when  REAL  PRECISION  has  selected  fixed-point  for  other  real 
numbers.  It  is  not  apparent  in  FIPS  PUB  128  what  the  precision 
of  this  floating  point  parameter  is  when  fixed  point  reals  have 
been  selected:  its  precision  shall  be  (0,9,23). 

3. 2. 1.4  Control  elements.  Control  element  constraints  shall  be 
as  specified  in  table  II. 


TABLE  II.  Control  element  constraints 


Element 

Basic  Values 

VDC  Integer  Precision 

16,  32 

VDC  Real  Precision 

(1,16,16)  (fixed) 

(0,9,23)  (floating  point) 

Transparency 

1  (on) 

Note:  VDC  stands  for  virtual  Device  Coordinates,  the  coordinate 

system  of  FIPS  PUB  128. 

3. 2. 1.5  Graphical  primitives.  To  ensure  portability  and 
predictable  results,  conforming  basic  metafiles  shall  not  contain 
any  Generalized  Drawing  Primitive  (GDP)  elements.  [Note:  Future 
addenda  to  this  specification  may  specify  GDP  elements  to  be 
included  in  the  Basic  set.] 

3.2. 1.6  Attribute  elements.  Attribute  element  constraints  snaLL 
be  as  specified  in  table  III. 
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TABLE  III.  Attribute  element  constraints 


Element 

Basic  Values 

Line  Bundle  Index 

1-5 

Line  Type 

1-5 

(Note  1) 

Marker  Bundle  Index 

1-5 

Marker  Type 

1-5 

Text  Bundle  Index 

1-2 

Text  Font  Index 

1-4 

Character  Set  Index 

•  1-2 

Alternate  Character  Set 

Index  1-2 

Fill  Bundle  Index 

1-5 

Hatch  Index 

1-6 

(Note  2) 

Edge  Bundle  Index 

1-5 

Edge  Type 

1-5 

Pattern  Table 

Starting  Index,  1-8 

nx. 

1-16 

ny, 

1-16 

Color  Table 

start  index  0-255 

Note  1:  Additionally,  the  linetypes  defined  in  3. 2. 2.1  shall  be 
included  in  the  Basic  Set  of  this  specification. 

Note  2:  Additionally,  the  hatch  styles  (indexes)  defined  in 

3. 2. 2. 2  shall  be  included  in  the  Basic  Set  of  this  specification. 

For  indexed  color  selection,  either  all  color  indexes  used  in  the 
metafile  shall  have  their  representations  defined  by  use  of  the 
COLOR  TABLE  element,  or  none  shall.  A  color  index  is  "used"  if 
it  occurs  in  an  element  selecting  a  color  value  to  be  applied  to 
a  primitive  (LINE  COLOR,  CELL  ARRAY,  etc) . 

3. 2. 1.7  Escape  element.  To  ensure  portability  and  predictable 
results,  CGM  application  profiles  conforming  to  this 
specification  may  contain  only  those  ESCAPE  elements  that  are 
defined  in  3.2.6. 

3. 2. 1.8  External  elements.  The  "action  required"  flag  of  the 
MESSAGE  element  shall  be  restricted  to  the  value  "no  action 
required. " 

3.2.2  Additional  attribute  values 

3.2.2. 1  Linetypes .  The  additional  linetypes  specified  in  table 
IV  shall  apply  (see  figures  1  through  10  for  examples) . 
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TABLE  IV.  Additional  linetvpes 


Linetype 

CGM  parameter  value 

chain  line 

-11301 

center  line 

-11302 

hidden  line 

-11303 

phantom  line 

-11304 

double  arrow 

-11305 

single  dot 

-11306 

single  arrow 

-11307 

stitch  line 

-11308 

break  line,  style  1 

-11309 

break  line,  style  2 

-11310 

3. 2. 2. 2  Hatch  styles.  The  additional  hatch  styles  specified  in 
table  V  shall  apply  (see  figure  11  for  examples) . 


TABLE  V.  Additional  hatch  styles 


Hatch  style 

CGM 

- ! 

parameter  value  j 

across  grain  wood 

-11401 

with  grain  wood 

-11402 

bronze,  brass,  copper,  and  compositions 

-11403 

cast  iron  or  malleable  iron  and 

general 

use  for  all  materials 

-11404 

steel 

-11405 

concrete 

-11406 

cork,  felt,  fabric,  leather,  and 

fiber 

-11407 

magnesium,  aluminum,  and  aluminum  alloys 

-11409 

;  marble,  slate,  glass,  porcelain. 

etc. 

-11410 

1  rock 

-11411 

rubber,  plastic,  and  electrical 

insulation 

-11412 

sand 

-11413 

sound  insulation 

-11414 

thermal  insulation 

-11415 

titanium  and  refractory  material 

-11416 

water  and  other  liquids 

-11417 

white  metal,  zinc,  lead,  babbitt 

,  and  alloys 

-11418 

3.2.3  FIPS  PDB  128  defaults.  FIPS  PUB  128  specifies  a  conplo'" 
set  of  defaults.  In  some  cases,  these  defaults  do  not  match  f? 
application  requirements  of  this  specification.  However, 
conforming  basic  metafile  satisfying  this  specification  shal.  : 
a  legal  CGM  as  specified  in  FIPS  PUB  128,  including  inpl:;.- 
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defaults.  Thus,  each  deviation  requires  that  the  affected 
element  shall  either: 

1.  Appear  in  the  METAFILE  DEFAULTS  REPLACEMENT  element,  or 

2.  Be  explicitly  specified  for  its  value  to  be  applicable. 

Therefore,  any  conforming  basic  metafile  satisfying  this 
specification  shall  contain  in  the  Metafile  Descriptor  a  METAFILE 
DEFAULTS  REPLACEMENT  element  that  includes  (at  a  minimum) : 

TEXT  PRECISION  element;  precision  2  (stroke) . 


3.2.4  Specification  of  semantic  FIPS  PUB  123 
leaves  the  semantics  of  a  number  of  graphical  details  unspecified 
or  "implementation  dependent."  This  is  unacceptable  where 
predictable  interchange  is  required.  The  following 
specifications  shall  apply  for  conforming  basic  generators  and 
interpreters  of  this  specification; 

3. 2. 4.1  View  surface  clearing.  Unless  clearing  is  suppressed  by 
•Escape  -301',  the  view  surface  shall  be  cleared  upon 
interpretation  of  the  Begin  Picture  Body  element. 

3. 2. 4. 2  Clipping.  When  the  clip  indicator  is  "off",  clipping 
shall  be  done  to  the  intersection  of  the  device  viewport  and  the 
device  view  surface  limits.  When  clipping  is  "on",  clipping 
shall  be  done  to  the  intersection  of  the  clip  rectangle,  the  VDC 
extent,  the  device  viewport  and  the  device  view  surface  limits. 

3. 2. 4. 3  Linetvpe  continuation.  Linetype  shall  be  maintained 
(continued)  across  the  interior  vertices  of  a  polyline. 

3. 2. 4. 4  Edge  type  continuation.  Edge  type  shall  be  maintained 
(continued)  across  the  vertices  of  a  filled  area  boundary. 

3.2.5  Font  specifications.  The  fonts  in  table  VI  are  public 
domain  fonts,  available  as  part  of  NBS  SP  424.  All  of  these 
fonts  shall  be  considered  basic  capabilities  of  a  basic  metafile 
conforming  to  this  specification.  Any  of  these  fonts  may  appear 
in  the  Font  List  element  in  a  basic  metafile  that  conforms  to 
this  specification.  Font  name  shall  be  the  concatenation  of  the 
string  "HERSHEY:",  to  designate  one  of  the  Hershey  fonts,  and  a 
"name  string"  to  designate  the  particular  typeface. 
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TABLE  VI.  Basic  font  names 


1. 

HERSHEY: CARTOGRAPHIC  ROMAN 

2. 

HERSHEY; CARTOGRAPHIC  GREEK 

3. 

HERSHEY: SIMPLEX  ROMAN 

4. 

HERSHEY: SIMPLEX  GREEK 

5. 

HERSHEY: SIMPLEX  SCRIPT 

6. 

HERSHEY: COMPLEX  ROMAN 

7. 

HERSHEY: COMPLEX  GREEK 

3. 

HERSHEY: COMPLEX  SCRIPT 

9. 

HERSHEY: COMPLEX  ITALIC 

10. 

HERSHEY: COMPLEX  CYRILLIC 

11. 

HERSHEY: DUPLEX  ROMAN 

12. 

HERSHEY: TRIPLEX  ROMAN 

13. 

HERSHEY: TRIPLEX  ITALIC 

14. 

HERSHEY: GOTHIC  GERMAN 

15. 

HERSHEY: GOTHIC  ENGLISH 

16. 

HERSHEY : GOTHIC  ITALIA 

3.2.6  Escape  elements.  Support  of  the  following  ESCAPE  elements 
shall  be  required  in  conforming  implementations  under  this 
specification. 

3.2.6. 1  Disable  clearing  of _ view  surface.  The  normal 

interpretation  of  a  CGM  metafile  is  such  that  the  view  surface  of 
a  device  is  cleared  on  each  Begin  Picture  Body  element.  This 
Escape  element  will  disable  the  clearing  of  the  view  surface  for 
all  of  the  pictures  in  the  metafile.  The  effect  of  this  Escape 
element  is  to  permit  multiple  metafile  pictures  to  be  imaged  on 
the  same  view  surface  with  a  mapping  as  described  in  FIPS  PUB 
128,  The  pictures  may  have  different  VDC  Extents.  Thus,  each 
picture  shall  be  mapped  into  the  current  device  viewport  (whether 
default  or  specified  by  the  Device  Viewport  Escape  element).  If 
used,  this  Escape  element  must  appear  in  the  Metafile  Descriptor. 
This  Escape  element  shall  be  a  basic  capability  of  the  CGM 
Application  Profile  under  this  specification. 

Escape  Identifier:  >301 

Escape  Data  Record:  null 

3. 2. 6. 2  Device  viewport.  The  default  device  viewport  is  the 
largest  rectangular  area  of  the  screen.  The  viewport  shall  be 
redefined  by  this  escape  element  by  specifying  two  corner  points. 
The  effective  viewport  shall  be  the  largest  rectangle  in  the 
viewport  having  the  same  aspect  ratio  as  the  VDC  extent,  and 
having  the  same  lower-left  corner  as  the  device  viewport.  The 
VDC  extent  shall  be  mapped  onto  the  effective  viewport  when  the 
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picture  is  interpreted.  The  units  with  which  the  two  points  are 
specified  shall  be  real  fractions  [0.0  to  1.0],  which  shall  be 
applied  to  the  device  viewport.  If  used,  this  Escape  must  appear 
in  the  Picture  Descriptor.  If  the  scaling  mode  has  been  set  to 
metric,  then  the  device  viewport  shall  have  precedence  —  the 
scaling  mode  shall  be  treated  as  if  it  were  abstract. 

Escape  Identifier:  -302 

Escape  Data  Record:  A  single  string  of  text 
containing  the  specification  of  the  viewport. 
Parameters  in  the  viewport  shall  be  separated  by 
at  least  one  blank  character  and/or  a  single  comma 
character.  The  decimal  point  of  the  real  fraction 
shall  be  required.  Leading  zeroes  of  the  real 
fraction  shall  be  optional.  There  are  four 
parameters: 

PI:  First  corner  x-coordinate.  Real  fraction 
of  the  default  device  viewport,  in  the  range 
[0.0, 1.0] . 

P2:  First  corner  y-coordinate.  Real  fraction 
of  the  default  device  viewport,  in  the  range 
[0.0, 1.0] . 

P3 :  Second  corner  x-coordinate.  Real 
fraction  of  the  default  device  viewport,  in 
the  range  [ 0 . 0 , 1 . 0 ] . 

P4 :  Second  corner  y-coordinate.  Real 
fraction  of  the  default  device  viewport,  in 
the  range  [0.0, 1.0]. 

Example:  a  viewport  equal  to  the  upper  right  quarter  of  the 
default  viewport  could  be  coded  as: 

Escape  Identifier  -302 

Escape  Data  Record  " . 5  .5  1 .  1 . ” 

This  Escape  element  shall  be  a  basic  capability  of  the  cgm 
Application  Profile  of  this  specification. 

3.2.6. 3  Implicit  Color  Table.  The  default  Color  Table  is 
undefined  in  FIPS  PUB  128.  It  is  always  possible  to  specify  an 
entire  default  Color  Table  with  Metafile  Defaults  Replacement. 
This  ESCAPE  element  shall  provide  a  shorthand  method  to  specify  a 
default  color  table  from  a  small  set  of  predefined  tables,  and 
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shall  provide  a  method  to  specify  how  the  interpreter  shall 
define  its  own  color  table  according  to  available  resources. 
This  ESCAPE  shall  be  allowed  in  the  Metafile  Descriptor.  If 
used,  no  COLOR  TABLE  elements  shall  appear  in  the  metafile.  The 
single  integer  parameter  of  the  ESCAPE  shall  have  the  following 
meanings: 


0:  ''none”  —  there  shall  be  no  implicit  default  value  of 

the  color  table,  interpreters  shall  associate 
representations  with  color  indexes  as  they  see  fit. 

1:  "cyclic”  —  the  interpreter  shall  initialize  its  color 

table  to  contain 

0  -  white 

1  -  black 

2  -  red 

3  -  green 

4  -  blue 

5  -  yellow 

6  -  magenta 

7  -  cyan 

8  -  black 

9  -  white 

10  through  255  -  cyclic  repetition  of  2-9. 

2:  "uniform”  —  the  interpreter  shall  initialize  its  color 

table  to:  black  and  white  in  indexes  0  and  1. 

Beginning  at  index  2,  224  representations  that  shall 

uniformly  sample  the  RGB  color  cube  as  follows: 

-  5  levels  of  red  evenly  spaced  from  none  to 

maximum; 

9  levels  of  green  evenly  spaced  from  none  to 
maximum; 

5  levels  of  blue  evenly  spaced  from  none  to 
maximum. 

The  color  cube  shall  be  mapped  to  the  linear  array  =/ 
varying  the  red  dimension  most  rapidly,  then  the  green 
dimension,  then  the  blue  dimension.  Note  that  the 
225th  element  implied  by  this  sequence,  black,  shall 
not  be  put  into  the  table.  Beginning  at  index  22  6 
shall  be  28  levels  of  gray.  Index  226  shall  be  1/  3  2 
(very  dark) .  Succeeding  entries,  with  the  exceptions 
described  below,  shall  be  1/32  lighter.  The  exceptions 
shall  be  0/32,  8/32,  16/32,  24/32,  32/32,  which  shal’. 

be  found  in  the  "color  cube”  section  of  the  table. 

The  default  value  shall  be  1,  "cyclic.” 
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Escape  Identifier:  -303 

Escape  Data  Record:  A  single  string  of  text 
containing  the  single  integer  parameter  of  this 
escape  element.  The  integer  is  encoded  as  "clear 
text",  i.e.,  value  2  is  encoded  as  the  string 
comprised  of  (or  containing)  the  ASCII  character 
"2". 


This  Escape  element  shall  be  a  basic  capability  of  the  CGM 
Application  Profile  of  this  specification. 

3.2.7  Implementation  dependencies.  This  section  specifies 
implementation  dependencies  and  environmental  constraints  for  CGM 
APS  conforming  to  this  specification. 

3. 2. 7.1  General  guidelines  for  FIPS  PUB  128  elements.  Unless 
otherwise  noted  in  this  specification,  the  guidelines  of  FIPS  PUB 
128  Annex  0  shall  apply  to  conforming  basic  generators  and 
interpreters  as  defined  in  3.1. 


Name:  Metafile  Defaults  Replacement 

Description:  The  Metafile  Defaults  Replacement  element 

shall  not  be  partitioned.  Note  that  FIPS  PUB 
128  permits  multiple  occurrences  of  this 
element,  so  that  partitioning  is  not 
required.  Partitioning  shall  be  permitted 
for  all  other  elements. 


Name: 


Restricted  Text 


Description:  Draft  level  capability  of  a  basic  conform :-.q 

interpreter  shall  be  to  render  the  complete 
restricted  text  string  (including  appendei 
text),  scaled  isotropically  (i.e.,  specified 
aspect  ratio  for  the  text  is  not  distorted: 
such  that  the  string  fits  into  the  text 
extent  parallelogram. 

Name:  Color  Table 


Description:  The  Color  Table  element  has  an  unspecified 

effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives.  I:  i 
Color  Table  element  defining  t-,  e 
representation  of  a  given  color  index  appears 
in  a  picture,  it  shall  appear  befsre 
reference  to  that  index  by  an  attribute 
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element  or  use  of  that  index  by  a  graphical 
primitive  element  (included  in  the  latter 
shall  be  implicit  use  of  default  color  index 
attribute  values  by  the  first  occurrence  of 
an  associated  primitive) .  Once  a  given  color 
representation  is  defined  and  used,  it  shall 
not  be  redefined.  [Note:  These  restrictions 
insure  that  interpreting  systems  without 
dynamic  color  update  capabilities  shall  be 
able  to  render  the  intended  picture 

accurately. ] 

Name:  Pattern  Table 

Description:  The  Pattern  Table  element  has  an  unspecified 

effect  when  it  appears  in  a  picture 
subsequent  to  any  graphical  primitives  filled 
with  the  affected  pattern  index.  If  a 

Pattern  Table  element  defining  the 
representation  of  a  given  pattern  index 
appears  in  a  picture:  a)  it  shall  appear 
before  explicit  reference  to  that  index  by 
any  Pattern  Index  element;  or  b)  in  the  case 
of  the  default  pattern  index,  it  shall  appear 
before  any  implicit  reference  caused  by  the 
first  occurrence  of  an  associated  filled 
primitive.  Once  a  given  pattern 
representation  is  defined  and  used,  it  shall 
not  be  redefined.  [Note:  These  restrictions 
insure  that  interpreting  systems  without 
dynamic  pattern  update  capabilities  shall  be 
able  to  render  the  intended  picture 

accurately. ] 

3.2.3  Implementation  requirements  for  conforming  basic 
generators  and  interpreters .  The  specifications  in  this  section 
shall  augment  those  of  FIPS  PUB  128,  Part  1,  annex  D.5,  and  Part 
3,  clause  8. 

3. 2. 8.1  Additional  generator  specifications.  This  specification 
states  that  the  values  of  attributes  (e.g.,  linetype)  shall  be 
restricted  to  a  certain  set.  When  a  conforming  basic  generator 
receives  (from  the  application  or  graphics  system  client)  a  value 
outside  of  the  Basic  set,  it  shall  be  handled  as  follows: 

If  the  index  is  selecting  an  attribute  (e.g.,  linetype), 
then  a  conforming  basic  generator  shall  map  it  to  the 
default  value  for  that  attribute; 
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If  the  index  is  defining  an  attribute  (e.g.,  color  table), 
then  it  shall  be  ignored  if  outside  the  Basic  range. 

These  choices  for  a  conforming  basic  generator  are  consistent 
with  Part  1,  annex  D  of  FIPS  PUB  128. 

Conforming  generators  shall  provide  to  applications  the  means  to 
either  select  the  implicit  color  table  for  a  metafile  (e.g.,  via 
a  mechanism  to  cause  generation  of  'Escape  -303')  or  to  ascertain 
the  value  that  will  be  used  in  the  metafile.  The  means  to 
ascertain  the  value  shall  consist  of  either  a  software  inquiry 
mechanism  or  documentation  accompanying  the  system.  An  inquiry 
mechanism  shall  be  the  preferred  method. 

3. 2. 8. 2  Additional  basic  interpreter  specifications.  In  the 
absence  of  any  color  table  elements,  or  of  ESCAPE  -303  (see 
3. 2. 6. 3),  in  the  metafile,  conforming  basic  interpreters  shall 
initialize  their  color  tables  as  follows:  index  0  shall  be  set 
to  white;  index  1  shall  be  set  to  black;  and  indexes  2-254  shall 
be  set  by  cyclic  repetition  of  the  8  entries  specified  in  table 
VII.  Draft  Level  conformance  for  interpreters  shall  allow  black 
and  white  to  be  reversed  in  the  first  two  indices. 


TABLE  VII.  Default  Color  Table 


Index 

Values 

Meaning 

2 

(1.0, 0,0) 

Red 

3 

(0, 1.0,0) 

Green 

4 

(0,0, 1.0) 

Blue 

5 

(1.0, 1.0,0) 

Yellow 

6 

(1.0, 0,1.0) 

Magenta 

7 

(0, 1.0, 1.0) 

Cyan 

3 

(0,0,0) 

Black 

9 

(1.0, 1.0, 1.0) 

White 

Note:  The  values  '1.0'  in  the  preceding  table  denote  full 

intensity  for  the  appropriate  component. 

3. 2. 8. 3  Minimmi  data  structure  suDDort.  The  following  named 
elements  shall  have  basic  values  as  defined  below: 

Name;  Maximum  Color  Array  Dimension 

Description:  The  basic  value  for  the  number  of  color 

values  that  can  appear  in  a  color  array  or 
color  list  parameter  shall  be:  1048576  for 
CELL  ARRAY  (one  1024x1024  image)  ;  2048  for 
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Name; 

Description: 

Name: 

Description: 

Name: 

Description; 


PATTERN  TABLE  (eight  16x16  patterns) ;  256  for 
COLOR  TABLE  (entries  0-255) .  CELL  ARRAY  and 
PATTERN  TABLE  have  color  array  parameters  and 
COLOR  TABLE  has  a  color  list  parameter. 

Maximum  Point  Array  Length 

The  basic  value  for  the  number  of  points  and 
VDC  that  can  appear  in  parameters  for 
metafile  elements  shall  be  1024. 

Maximum  String  Length 

The  basic  value  for  the  length  of  an 
individual  string  of  characters  shall  be:  254 
for  all  string  parameters  except  data 
records;  32767  for  data  records. 

Bundle  Table 

Bundle  representations  are  not  settable  in 
the  current  version  of  FIPS  PUB  128.  To 
insure  predictable  results,  interpreters  and 
generators  conforming  to  the  COM  Application 
Profile  of  this  specification  shall  use  the 
default  values  from  table  VIII. 
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TABLE  VIII.  Default  bundle  tables 


Bundle  Type 

1 

Bundle 

2  3 

Index 

4 

5 

Line  Bundle 

Line  Type 

solid 

dash 

dot 

dash-dot 

dash-dot-dot 

Line  width 

1 

7 

1 

1 

1 

Line  Color 

1 

1 

1 

1 

1 

Marker  Bundle 

Marker  Type 

dot 

plus 

asterisk  circle 

cross 

Marker  Size 

1 

1 

1 

1 

1 

Marker  Color 

1 

1 

1 

1 

1 

Text  Bundle 

Font  Index  1 

Text  Precision  stroke 
Character 

Expansion  Factor  1 
Char.  Spacing  0 
Text  Color  1 

1 

stroke 

0.7 

0 

1 

Fill  Bundle 

Interior  Style 

hatch 

hatch 

hatch  hatch 

hatch 

Fill  Color 

1 

1 

1 

1 

1 

Hatch  Index 

1 

2 

3 

4 

5 

Pattern  Index 

1 

1 

1 

1 

1 

Edge  Bupd^e 

Edge  Type 

solid 

dash 

dot 

dash-dot 

dash-dot-dot 

Edge  Width 

1 

1 

1 

1 

1 

Edge  Color 

1 

1 

1 

1 

1 
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4.  QUALITY  ASSURANCE  PROVISIONS 

4.1  Responsibility  for  inspection.  Unless  othervise  specified 
in  the  contract  or  purchase  order,  the  contractor  is  responsible 
for  the  performance  of  all  inspection  requirements  (examinations 
and  tests)  as  specified  herein.  Except  as  otherwise  specified  in 
the  contract  or  purchase  order,  the  contractor  may  use  his  own  or 
any  other  facilities  suitable  for  the  performance  of  the 
inspection  requirements  herein,  unless  disapproved  by  the 
Government.  The  Government  reserves  the  right  to  perform  any  of 
the  inspections  set  forth  in  the  specification  where  such 
inspections  are  deemed  necessary  to  ensure  that  supplies  and 
services  conform  to  prescribed  requirements. 

4.2  Responsibility  for  compliance.  All  items  shall  meet  all 
requirements  of  section  3.  The  inspection  set  forth  in  this 
specification  shall  become  a  part  of  the  contractor's  overall 
inspection  system  or  quality  program.  The  absence  of  any 
inspection  requirements  in  the  specification  shall  not  relieve 
the  contractor  of  the  responsibility  of  ensuring  that  all 
products  or  supplies  submitted  to  the  Government  for  acceptance 
comply  with  all  requirements  of  the  contract.  Sampling  in 
quality  conformance  does  not  authorize  submission  of  known 
defective  material,  either  indicated  or  actual,  nor  does  it 
commit  the  Government  to  acceptance  of  defective  material. 

4.3  Inspection  procedures.  All  entities,  attributes  and 
parameter  values  shall  be  analyzed  for  conformance  to  FIPS  PUB 
128  and  to  section  3  of  this  specification  for  a  conforming  basic 
metafile.  This  shall  be  accomplished  with  an  appropriate 
software  utility,  or  conformance  test  suite.  All  conforming 
basic  metafiles  contained  in  a  particular  CGM  application  profile 
shall  be  displayed  and  checked  visually  for  conformance  to  the 
requirements  of  FIPS  PUB  128  and  of  section  3  in  its  entirety. 

4.3.1  Font  rendering.  Font  names  shall  be  specified  in  a  manner 
compatible  with  ISO  DIS  9541,  Font  and  Character  Information 
Interchange,  when  it  becomes  stable.  Until  then,  this 
specification  shall  consider  any  rendering  of  a  requested  font 
conforming  if  the  rendering  is  "metrically  identical"  to  the  font 
metrics  of  the  requested  font.  This  means  that  the  placement  and 
alignment  of  the  string  and  the  placement,  size,  and  shape  of 
individual  characters  (i.e.,  the  drawn  portions  of  the  character 
cells)  shall  be  measurably  identical.  This  does  allow  a  good 
quality  filled  font  to  be  substituted  for  a  stroked  Hershey  font, 
for  example.  Finally,  the  Hershey  "fonts"  are  really  a  mixture 
of  fonts  and  character  sets  (e.g.,  Greek  is  a  character  set). 
The  requirements  of  this  specification  shall  be  served  ty 
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providing  that  the  necessary  character  sets  be  supported  in  part, 
and  the  necessary  typefaces  be  supported  in  part,  so  that  the 
combinations  required  to  render  the  listed  16  Hershey  "fonts" 
shall  be  supported  in  full.  It  is  recognized  that  the  Hershey 
fonts  may  not  be  of  adequate  quality  for  modern  publication 
requirements. 

4.3.2  Error  processing.  A  conforming  CGM  interpreter  shall 
gracefully  recover  from  any  exception  condition.  If  there  is 
something  which  is  not  understood  by  the  interpreter,  then  if 
possible  that  element  should  be  skipped,  appropriate  error 
warnings  generated  or  logged,  and  interpretation  continue  with 
the  next  element  following  the  problem  element. 
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5 .  PACKAGING 

Packaging  of  illustration  data  files  for  delivery  shall  be  in 
accordance  with  the  requirements  of  MIL-STD-1840 . 

6.  NOTES 

6.1  Intended  use.  This  specification  is  designed  to  be 
incorporated  into  a  contract  to  define  the  technical  requirements 
to  be  met  when  it  is  desired  to  purchase  illustration  or  picture 
description  data  (in  contrast  to  product  definition  data)  in 
digital  form  for  use  in  technical  illustrations  and  technical 
publications.  A  CGM  AP  under  this  specification  represents 
illustration  data  in  the  form  of  a  conforming  basic  metafile, 
i.e.,  it  contains,  in  device-,  system-,  and  implementation- 
independent  form,  the  picture  description  data  represented  by  the 
functions  invoked  through  an  application  program  interface.  A 
CGM  AP  contains  the  allowable  output  primitives  and  attributes 
which  may  be  used  to  compose  the  picture.  In  addition,  the  CGM 
AP  of  this  specification  specifies  certain  constraints  on  cgm 
generators  and  interpreters  to  remove  implementation 
dependencies,  thereby  serving  to  ensure  predictable  interchange 
of  conforming  basic  metafiles  between  clients. 

6.1.1  Explanation  of  CGM  AP.  The  syntactic  specification  in  the 
FIPS  PUB  128  is  complete  and  unambiguous.  It  is,  as  well, 
redundant  in  the  sense  that  there  are  three  distinct  encodings  of 
the  same  functionality:  binary,  character,  and  clear  text.  The 
redundancy  serves  a  useful  purpose,  as  each  encoding  is  tailored 
to  certain  computing  environments  and  applications,  and  so  rhe 
CGM  client  has  the  opportunity  to  choose  a  syntax  that  : 
optimized  to  the  intended  application.  The  binary  encoding  ms 
been  chosen  as  the  only  encoding  which  will  be  supported  by  tr.  :3 
military  specification  at  this  time. 

The  semantic  specification  is  less  complete.  The  expected 
overall  results  of  using  the  geometric  primitive  elements  ire 
well  enough  specified.  However  some  of  the  finer  details,  sucn 
as  the  precise  appearance  of  joints  and  endpoints  in  lines,  jre 
unspecified.  This  underspecification  of  semantics  -is 
intentional  on  the  part  of  the  standards  committees  formulatiri 
the  CGM  standard,  since  it  allows  a  wider  range  of  exist  in 
systems  to  be  accommodated  and  makes  the  standard  more  adapt irl*? 
to  the  various  needs  and  philosophies  of  a  diverse  clientele. 

On  the  other  hand,  the  semantic  ambiguity  does  mean  that  ttor-.’ 
will  be  no  single  correct  interpretation  of  a  given  CGM  metafi.', 
and  hence  it  will  be  difficult  to  unambiguously  describe  i - 
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intended  picture  using  the  CGM  standard.  This  is  a  distinct 
drawback  in  certain  application  environments,  such  as  the  areas 
of  Technical  Illustration  and  Technical  Publishing. 

There  are  further  sources  of  uncertainty  in  using  CGM  in  an 
application  environment.  A  CGM  metafile  is  produced  by  a 
component  of  a  graphics  environment  known  as  a  "metafile 
generator."  The  content  of  a  CGM  metafile  is  rendered  into 
pictures  by  a  component  known  as  a  "metafile  interpreter."  FIPS 
PUB  128  specifically  excludes  standardization  of  the  behavior  of 
metafile  generators  and  metafile  interpreters.  (Most  such 
behavior  is  described  as  "implementation  dependent.")  In  doing 
so,  a  certain  unpredictability  of  results  is  introduced  into  the 
graphics  system  viewed  as  a  whole;  for  example,  CGM  generators 
serving  GKS  (Graphical  Kernel  System,  ANSI  X3.124)  clients  in  the 
product  lines  of  two  different  vendors  might  map  out-of-range 
attributes  differently. 

These  two  sources  of  ambiguity  in  using  the  CGM  standard — 
incomplete  semantics  and  non-specification  of  the  behavior  of 
generators  and  interpreters— do  not  diminish  the  utility  of  FIPS 
PUB  128  for  technical  illustration  and  technical  publishing.  It 
is  a  sound  and  suitable  basic  protocol  for  these  areas.  But  they 
do  mean  that  some  further  specification  (beyond  that  in  the 
published  standard)  is  required  in  order  for  the  use  of  the  CGM 
standard  to  be  effective  and  unambiguous. 

Such  a  specification  is  precisely  what  an  Application  Profile 
(AP)  consists  of.  In  the  case  of  CGM,  an  AP  specifies: 

1.  complete  semantics; 

2.  the  behavior  of  CGM  generators  and  CGM  interpreters; 

An  AP  specifies  minimal  and  maximal  requirements  for  generators 
and  interpreters,  and  ties  down  all  implementation  dependencies 
of  the  CGM  metafile.  As  the  name  suggests,  the  AP  for  CGM  is  a 
set  of  specifications  appropriate  to  a  given  application 
environment. 

6.1.2  Metafile  Descriptor  Elements.  It  is  unclear  in  FIPS  PUB 
128  whether  there  should  be  a  mandatory  ordering  of  Metafile 
Descriptor  elements  (the  grammar  implies  some) .  Addendum  1  of 
FIPS  PUB  128  will  impose  such  an  ordering  when  it  becomes  part  of 
the  standard.  This  is  to  point  out  that  such  an  ordering  may 
become  mandatory  in  a  future  revision  of  this  specification. 
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6.1.3  Additional  attribute  values. 

6. 1.3.1  Linetvpes.  The  linetypes  specified  in  table  IV  of 

3. 2. 2.1  have  been  submitted  to  ANSI  and  ISO,  the  International 
Standards  Organization,  for  graphics  registration  (see  figures  i 
through  10  for  examples) .  The  figures  for  these  linetypes  are 
taken  from  the  latest  draft  of  the  registration  proposals  that 
have  been  submitted  to  ANSI  and  ISO.  In  table  IV,  the  name  of 
the  linetype  is  given,  followed  by  the  numeric  value  (the 
linetype  parameter)  by  which  it  is  to  be  referenced.  These 
references  may  change  in  future  amendments  to  this  specification. 

6. 1.3.2  Hatch  styles.  The  hatch  styles  in  table  V  of  3. 2. 2. 2 
have  also  been  submitted  for  graphical  registration  (see  figure 
11  for  examples) .  The  hatch  style  examples  of  figure  11  are 
taken  from  ANSI  Y14.26,  Engineering  Drawing  and  Related 
Documentation  Practices — Digital  Representation  for  Communication 
of  Product  Definition  Data.  In  table  V,  the  name  of  the  hatch 
style  is  given,  followed  by  the  numeric  value  (the  hatch  index 
parameter)  by  which  it  is  to  be  referenced.  This  reference  may 
change  in  future  amendments  to  this  specification. 

6.2  Ordering  data.  The  contract  or  purchase  order  should 
specify  the  following: 

a.  Title,  number,  and  date  of  this  specification. 

b.  The  application  profile  should  specify  whether  it  is 
meant  for  publication  level  or  draft  level 
interpretation.  (See  3.1.2) 

6 . 3  Definitions. 

6.3.1  Acronyms  and  abbreviations  used  in  this  specification. 
Acronyms  and  abbreviations  used  in  this  specification  are  derir.ei 
as  follows: 

a.  ANSI  -  The  American  National  Standards  Institute. 

b.  AP  -  Application  Profile. 

c.  CGM  -  Computer  Graphics  Metafile.  Synonymous  with  Firs 

PUB  128. 

d.  DIS  -  Draft  International  Standard. 

e.  FIPS  -  Federal*  Information  Processing  Standards. 

f.  GDP  -  Generalized  Drawing  Primitive. 
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g.  GKS  -  Graphical  Kernel  System. 

h.  ISO  -  International  Standards  Organization. 

i.  PUB  -  Publication. 

j.  SP  -  Special  Publication. 

k.  VDC  -  Virtual  Device  Coordinates,  the  coordinate  system 
of  FIPS  PUB  128. 

6.3.2  Application  Profile.  A  specification  that  defines  the  use 
of  a  standard,  and  defines  all  possible  data  streams  that  conform 
to  that  profile.  An  AP  insures  interoperability  of 
different/multiple  implementations  of  a  standard.  In  this 
context,  it  completely  and  unambiguously  represents  the 
information  requirements  for  a  particular  application  of  digital 
graphics  data. 

6.3.3  Basic  values.  The  subset  of  permissible  values  for 
parameters  of  a  CGM  element  that  are  mandatory  for  conformance 
to  this  specification. 

6.3.4  Computer  Graphics  Metafile.  The  specification  for  a 
mechanism  for  storing  and  transferring  illustration  data.  Refer 
to  FIPS  PUB  128. 

6.3.5  Conforming  basic  generator.  A  metafile  generator  that 
produces  only  conforming  basic  metafiles  (or  can  be  reliably 
commanded  to  function  in  that  mode) ,  and  additionally  conforms  to 
any  additional  generator  requirements  as  explained  in  section  3 . 

6.3.6  Conforming  basic  interpreter.  An  metafile  interpreter 
that  at  least  correctly  interprets  any  conforming  basic  metafile, 
and  conforms  to  any  additional  interpreter  requirements  as 
explained  in  section  3 . 

6.3.7  Draft  level.  The  metafile  interpreter  level  for  all 
documents  except  those  for  final  document  production. 

6.3.8  Metafile.  Synonymous  with  CGM.  A  representation  for  the 
storage  and  transfer  of  graphical  data  and  control  information. 
This  representation  contains  a  device-independent  description  of 
one  or  more  pictures. 

6.3.9  Metafile  generator.  The  software  or  hardware  that  creates 
a  picture  or  conveys  information  in  the  CGM  representation. 
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6.3.10  Metafile  interpreter.  The  software  or  hardware  that 
reads  a  CGM  metafile  and  interprets  the  contents. 

6.3.11  Penaissible  values.  The  range  of  values  for  a  parameter 
of  a  CGM  element  as  specified  in  FIPS  PUB  128. 

6.3.12  Publication  level.  The  metafile  interpreter  level  for 
final  document  production. 

6.3.13  Vector  Graphics.  The  presentation  or  storage  of  images 
as  sequences  of  line  segments. 

Note:  Refer  to  FIPS  PUB  128,  clause  3,  for  further  definitions 

of  computer  graphics  terms. 

6 . 4  Subject  term  ^keyword)  listing. 

Application  profile 
CGM 

CGM  metafile 

Digital 

FIPS  PUB  128 

Technical  illustrations 

Technical  publications 
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Pf  ■ntitlon  dif  of  propoMi;  I  10  AonI  1987 


yi-t-iit  f-BCCl 


Authorit 


riaaa  of  GflOhICPi  ItPlH! 


LlNETVPe 


sinqip  arrow 


Daserlptlon _ 


A  singla  arrow  linatypa  consists  of  a  solid  llna  isrminaMd  By  an  arrowhaad  as  spscifisd  m  ANSI  Y14.2M-1979 
(Lins  Convsntions  and  Lsttsnng)  rsquirsmsnts  for  dimsnsion  and  Isadsr  linsa.  Ths  arrow  is  rsndarod  so  that  ths 
arrow  tip  occurs  at  ths  last  point  of  ths  list  of  points  passsd  to  a  polylins  and  is  in  ths  dirsction  of  ths  last 
vector. 

This  linetyps  is  intended  for  use  m  engineering  drawings. 

Specific  details  are  implementation  dependent  Ths  appearance  of  ths  degenerate  case  is  implementation 
dependent 

Such  a  linetvoe  has  the  followinq  visual  aooearance: 


Additional  Comments  _ 


The  requirements  stated  in  ANSI  yi4.2M*l979  shall  be  followed  when  rendering  this  linotype. 


This  linetype  is  not  intended  to  be  used  as  an  edgotype. 


Justification  for  Inclusion 


This  linetype  is  commonly  used  m  enginoenng  drawings.  It  is  one  of  a  set  of  linotypes  to  be  registered  'or  ..s 
with  computer  graohics  standards  to  enaoie  compact  storage  and  transfer  of  engineonng  drawings. 


Relationship  to  Standards 


1)  ISO  7942  (GKS)  ■  Specifies  a  registered  linetype  to  supplement  those  defined  in  S.4.1. 

2)  ISO  8632  (COM)  •  Specifies  a  registered  linetype  to  supplement  those  defined  in  5.7.2. 

3)  ANSI  Y14,2M-1979  -  L.ne  Conventions  and  Lettering. 
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lEZmilQlEC 


roposal:  1  10  April  1987 


nKiSEnnrBii 


Sponsorin 


Claat  ot  Graphical  Item: 


LINETYPE 


Name:  I  singla  dot 


Oaacriptipn _  _ 


A  single  dot  iinetype  consists  ot  a  solid  tins  terminated  tsy  a  dot  as  specified  m  ANSI  Y14.2M-1979  (Line 
Conventions  and  Lettenng)  raquiraments  for  leader  lines.  The  dot  is  rendered  so  that  the  dot  occurs  at  the  last 
point  in  the  list  of  points  passed  to  a  polyline. 

This  linetype  is  intended  for  use  in  engineering  drawings. 

Specific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 
dependent. 

Such  a  linetype  has  the  following  visual  appearance: 


Additional  Comments 


The  requiramonts  stated  m  ANSI  yi4  2M-t979  snail  be  followed  when  rendenng  this  linetype. 


This  linetype  is  not  intended  to  oe  used  as  an  edgetype. 


Justification  for  Inclusion 


his  iinatype  -s  commoniy  used  'n  engineenng  orawmgs.  it  is  one  of  a  set  of  'inetypes  registered  or  use  «i;n 
comoutar  graonics  standards  to  enaoie  compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Standards 


t)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those  defined  m  5.4.1. 

2)  ISO  8632  (CGM)  -  Specifies  a  registered  linetype  to  supplement  those  defined  m  5.7  2. 

3)  ANSI  Y14  2M-1979  ■  Lina  Conventions  and  Lettering. 


FIGURE  2:  Example  ol 


inetvpe  sinqlt 
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l_Pro£OMj__Nunjb#rJ^ 

I  PfTiftlon  d«f  of  propoMi:  |10  AonI  1987 


SDonsorIna  Authority:  1  ANSI 

Claaa  of  Graohleal  Itam:  I  UNblVPE 

Namo:  1  doublo  arrow 

Ooaerlptton 

A  doublo  arrow  linotypo  consists  of  a  solid  lino  torminatod  by  two  arrowhoada  as  spacifiod  in  ANSI 

Y14.2M-1979  (Lino  Convontions  and  Lettering)  raquiromonts  for  dimension  linos.  Tho  arrows  are  rondored  so 
that  tho  arrow  tip  occurs  at  tho  first  and  last  points  m  tho  list  of  points  passed  to  a  polyline. 

This  linotype  is  intended  for  uso  m  engineering  drawings. 

Specific  dotails  are  impiomontation  dependent  The  appearance  of  the  degenerate  case  is  implementation 
dependent 

Such  a  linotype  has  the  following  visual  appearance: 

J  k 

^  F 

Additional  Comments 

The  requirements  stated  m  ANSI  Y14  2M>1979  shall  be  followed  when  rendering  this  linotype.  i 

This  linotype  is  not  intended  to  be  used  as  an  edgetype. 

1 

1 

i 

Justification  for  Inclusion 

This  inatype  >s  commonly  used  n  engineenng  drawings.  It  'S  one  of  a  sol  of  moiypes  registered  for  use  wi:n 
comouter  grapnics  standards  to  enaoie  compact  storage  and  transfer  of  engineering  drawings. 

Relationship  to  Standards 

1)  ISO  7942  (GKS)  -  Specifies  a  registered  linotype  to  supplement  those  defined  m  5.4  t. 

2)  ISC  3632  (COM)  ■  Specifies  a  registered  linotype  to  supplement  those  defined  m  5.7  2. 

3)  ANSI  Y14  2M-t979  •  Line  Conventions  and  Lettering. 

FIGURE  3:  Example  of  linetvpe  double  arrow. 
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I  Proposal  Number:  I  5 


Soonsorlna  Authority:  1  ANSI 

Class  of  Graphical  Item:  I  LINETYPE 

Name:  1  stitch  ime 

1 

A  stitcn  Imp  ilnatypp  consists  of  Oasnes  and  spacas  of  aqual  langtn  as  spaciflad  m  ANSI  V14  2M-1979  (Una 
Convantions  and  Lattanng.) 


This  hnatypa  is  intended  for  use  n  engineering  drawings.  Its  definition  contains  rendition  raauiramants  oeyond 
those  for  the  dasned  unetype  already  present  in  the  graphics  standards. 

Specific  details  are  implementation  dependant.  The  appearance  of  the  degenerate  case  is  implementation 
dependent 

Such  a  lire  has  the  following  visual  appearance: 


Additional  Comments 

The  requirements  stated  m  ANSI  Yl4.2M-t979  shall  be  followed  when  ranoanng  this  linetype.  In  some  cases  t 
s  necn'sary  for  the  standard  (e  g.  GKS)  to  exercise  precise  control  over  the  manner  m  which  two  ires  ntersect 
n  a  drawing.  In  these  cases  it  may  oe  approonate  for  the  client  to  simulate  this  linetype  Oy  using  sequences  of 
correctly  placed  ndividuai  'me  segments. 

fhis  inetype  s  not  ntenoed  ’O  oe  used  as  an  edgetype. 


Justification  ‘or  Inclusion 

"hiS  metype  s  commoniy  ^sed  n  engmeenng  drawings.  It  s  one  of  a  set  of  metypes  registered  ‘or  ..se 
:oiTputer  g.-aohics  standards  to  enaoie  comoact  storage  and  'ranster  of  engineering  orawings. 


I 

Relationship  to  Standards 

f)  ISO  7942  (GKS)  ■  Specifies  a  registered  linotype  to  supplement  those  defined  m  5.4  i 

2)  ISO  8632  (CGM)  ■  Specifies  a  registered  linotype  to  supplement  those  defined  m  5.7  2. 

3)  ANSI  Yr4  2M-t979  •  L.ne  Conventions  and  Lettering. 


FIGURE  4 :  Example  of  linetvpe  stitch  line. 
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I  Pro^sal  NumbT:  1*6 

I  Pf  ■•nf  tion  d>f  of  pfOOO««l!  I  10  Aonl  1987 


Snon«oflna  Authority:  I  ANSI  ~ 

Cliis  ot  Gf  otilcil  If  w;  I  U^ETVre 

Niiw;  I  chain  lirr  ! 

0«»eflptlon 

A  Cham  line  linatyps  consista  of  altamating  long  and  short  dashaa  as  spacifiad  in  ANSI  Y14.2M-1979  (Lma 
Convantions  and  Lattanng.) 


This  linatypa  is  mtandad  for  usa  in  anginaanng  drawings.  Its  randition  is  diffarant  from  that  of  tha 
dashad-dottad  llnastyla  alraady  prasant  m  tha  graphics  standards. 


Spacific  datails  ara  implamantation  dapandant.  Tha  appaatranca  of  tha  daganarata  casa  is  impiamantation 
depandant. 

Such  a  lina  has  tha  following  visual  appaaranca: 


Additional  Comrwants 

Tha  raquiramants  statad  m  ANSI  Y14.2M>1979  shall  ba  followad  whan  ranoanng  this  linatypa.  In  soma  cases,  t 
s  nacassary  for  tha  standard  (a.g.  GKS)  to  exarcisa  pracisa  control  ovar  tha  mannar  in  which  two  nnes  ntersaci 
in  a  drawing.  In  thasa  cases  it  may  ba  appropnata  for  tha  client  to  simulate  this  linatypa  by  using  saouences  of 
correctly  placed  individual  line  segments. 


This  linetypa  is  not  intended  to  ba  used  as  an  edgatypa. 


I  Justification  for  Inclusion 

{  This  ineryoa  is  commonly  used  m  enginaanng  drawings.  It  is  one  of  a  set  of  inerypes  I'sgistered  ‘or 
:  comouter  graonics  standards  to  enable  comoact  storage  and  transfer  of  engineering  drawings. 


..se  wi!" 


Relationship  to  Standards 

1)  ISO  7942  (GKS)  ■  Specifies  a  registered  linatypa  to  supplement  those  defined  m  5.4  t 

2)  ISO  8632  (CGM)  •  Specifies  a  registered  linatypa  to  supplement  those  dermed  m  5.7  2. 

3)  ANSI  Y14  2M-1979  -  Lina  Conventions  and  Lettanng. 


FIGURE  5:  Example  of  linetvpe  chain  line. 
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Proposal  Numbor:  ^ 


[■•JTtl'I.U-nHi 


Soonsorlna  Authorit 


roDotal:  I  10  April  1987 


Class  of  Graphical  Itam;  |  LINETYP€ 


canter  line 


0  ascription _ 


A  center  line  iinetype  consists  of  alternating  long  and  snon  dasnes  as  specified  m  ANSI  yi4  2M-i979  (Una 
Conventions  and  Lettenng.) 

This  Iinetype  is  intended  for  use  m  angmaenng  drawings.  The  long  dashes  rnay  vary  m  length  depending  on  the 
Size  of  the  drawing.  Lines  drawn  m  this  iinetype  snail  start  and  end  with  long  dashes.  A  very  short  me  may  oe 
anOroKen. 

Specific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 
dependent. 


Such  a  line  has  the  following  visual  aoosaranca: 


Additional  Comments 


The  reguirements  stated  m  ANSI  Y14.2M'1979  shall  Pe  followed  when  renoenng  this  iinetype.  In  some  cases. 
.3  necessary  for  the  standard  (e.g.  GKS)  to  exercise  precise  control  over  the  manner  m  which  two  center  mes 
intersect  m  a  drawing.  In  these  cases  it  may  Qe  aopropnate  for  the  client  to  simulate  this  iinetype  Dy  usmg 
seduences  of  correctly  placed  mdividuaf  line  segments. 


rhis  Iinetype  is  not  intended  to  oe  used  as  an  edgetype. 


Justification  for  Inclusion  _ 


IS  instyps  s  commoniy  used  in  engineenng  drawings,  it  :s  one  of  a  set  of  imetypes  registered  ‘or  use  mi; 
j  comouter  graphics  standards  to  enaoie  compact  storage  and  transter  of  engineering  drawings. 


Relationship  to  Standards 

1)  ISO  7942  (GKS)  ■  Specifies  a  registered  imetype  to  supplement  those  defined  m  5  4  1 

2)  ISO  8632  (COM)  ■  Specifies  a  registered  iinetype  to  supplement  those  defined  n  S.7  2. 

3)  ANSI  Y14  2M-1979  ■  Line  Conventions  and  Lettering. 
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I  Proaoul  NuwbT:|8 


Praaantatlon  data  ot  oroDOtal:  1  10  Aoril  1987  | 

Soonaorina  Authority:  1  ANSI  1 

Clata  ot  Graphical  Itam:  I  LINbrYPf: 

Nama:  1  hidden  line 

□  aacriotlon 

A  hidden  line  iinetype  consists  ot  short  evenly  spaced  dashes  as  specified  in  ANSI  Y14.2M-1979  (Line 

Conventions  and  Lettenni}.) 

This  Iinetype  is  intended  for  use  m  engineenng  drawings.  The  dashes  may  vary  in  length  depending  on  the  size  ot 
the  drawing.  Lines,  not  polylines,  drawn  m  this  Iinetype  shall  start  and  and  with  a  dash.  Dashes  will  join  at 
corners,  and  arcs  drawn  with  this  style  shall  start  and  end  with  dashes.  These  rendition  requirements  are 
different  from  the  dashed  Iinetype  already  defined  m  the  graphics  standards. 

Specific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 
dependent 

Such  a  line  has  the  followinq  visual  aooearance: 

1 

Additional  Comments  | 

The  requirements  stated  in  ANSI  yu.2M-l979  shall  oe  followed  when  randenng  this  Iinetype.  In  some  cases.  i  i 
'S  necessary  for  the  standard  (a.g.  GKS)  to  exercise  precise  control  over  the  manner  in  which  two  lines  intersect  l 
m  a  drawing.  In  these  cases  it  may  be  appropnate  for  the  client  to  simulate  this  Iinetype  by  using  sequences  of 
correctly  placed  individual  line  segments. 

This  Iinetype  is  not  intended  to  be  used  as  an  edgatype. 

Justltleatlon  for  Inclusion 

This  linotype  'S  commonly  used  m  enginoenng  drawings.  It  is  one  of  a  set  of  tinetypos  registered  for  jse  rvitn 
computer  graphics  standards  to  enable  compact  storage  and  transfer  of  engineering  drawings. 

Relationship  to  Standards 

1)  ISO  7942  (GKS)  •  Specifies  a  registered  iinetype  to  supplement  those  defined  m  5.4.1. 

2)  ISO  8632  (CGM)  ■  Specifies  a  registered  iinetype  to  supplement  those  defined  in  5.7  2. 

3)  ANSI  Y14  2M-1979  -  Line  Conventions  and  Lettering. 
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FIGURE  7: 


MIL-D-28003 


I  Prooof  *  Nufnb>f:|9  | 

I  Pf»»ntatlon  d«f  of  prooo««l:  I  10  April  1987  T 

Soontortnq  Authority:  I  ANSI 
Cla»  o*  Graphical  lt>fn:  |  LINETVPE 

Naw;  I  phantom  ine 
Daaerlptlon 

A  pnantom  lin*  linstyp*  consists  of  long  dasnaa  saparatad  by  pairs  of  snort  dasnaa  as  specified  m  ANSI 
Y14.2M-1979  (Lina  Conventions  and  Lettering.) 

This  linetvpe  Is  ir.tended  for  use  m  engineering  drawings.  Lines,  not  polylines,  drawn  m  this  iinetype  snail  start 
and  and  ivith  long  dasnes  which  may  vary  n  lengin  depending  on  the  size  of  the  drawing. 

Specific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 
dependent 

Such  a  line  has  the  following  visual  appearance: 


Addltfonaf  Cammanfs  I 

The  requirements  stated  m  ANSI  VIA  2M*1979  shall  be  followed  when  randenng  this  iinetype.  in  soma  cases,  i  i 
IS  necessary  for  the  standard  (e.g.  GKS)  to  exorcise  precise  control  over  the  manner  in  which  two  lines  ntersect  | 
m  a  drawing.  In  these  cases  it  may  be  appropnats  for  the  client  to  simulate  this  iinetype  oy  using  sequences  of  | 
correctly  placed  individual  iine  segments.  < 

This  iinetype  s  not  intended  to  be  used  as  an  edgeiype. 


I  Justification  for  Inclusion  _ 

I  This  inetype  s  commonly  used  in  engineenng  drawings.  It  is  one  of  a  set  of  iinerypes  I’egistered  'or  ^se  r*i'."i 
!  computer  graomcs  standards  to  enable  compact  storage  and  transfer  of  engineering  drawings. 


Relationship  to  Standards 

t)  ISO  7942  iGKS)  ■  Specifies  a  registered  iinetype  to  supplement  those  defined  m  S.4  i. 

2)  ISO  8832  (CGM)  ■  Specifies  a  registered  iinetype  to  supplement  those  defined  m  5.7  2. 

3)  ANSI  Yf4  2M-l979  •  L  ne  Conventions  and  Lettering. 


FIGURE  3:  Example  of  Iinetype  phantom  line. 
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Preootal  Number:  I  1  0 


L^ij  1 1  i.it  IE 


roDoaal:  I  10  Aonl  1987 


Soonaorina  Authorit 


nE!2SI 


LINETVPE 


Nama:  I  break  line  •  style  i 


Oeacrlptlon _ 


A  break  line  linetype  •  style  i  ■  consists  of  either  one  of  two  allowable  representations  as  specified  m  ANSI 
Y14.2M-1979  (Line  Conventions  and  Lattanng.)  This  is  simply  a  line  having  a  'freehand*  appearance. 

This  linetype  is  intended  for  use  m  engineering  drawings. 

Soecific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 
dependent. 


Such  a  line  has  the  following  visual  appearance: 


Additional  Comments 


The  requirements  stated  m  ANSI  Y14.2M-1979  shall  be  followed  when  rendering  this  linetype. 
This  linetype  is  not  intended  to  be  used  as  an  edgetype. 


JustIfIcetlon  for  Inclusion 


This  linotype  is  commonly  used  in  engineenng  drawings,  it  is  one  of  a  sal  of  imetypes  registered  'or  jse 
computer  grapnics  standards  to  enable  compact  storage  and  transfer  of  engineering  drawings. 


Rslatlonshlo  to  Standards 


1)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those  defined  m  5.4  1. 

2)  IS  3632  (COM)  ■  Specifies  a  registered  linetype  to  supplement  those  defined  m  5.7  2. 
31  ANSI  Y14  2M-1979  •  Line  Conventions  and  Lettering, 


FIGURE  9 :  Example  of  linetype  break  line,  style  L 


I 
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I  PfOOO»«l  Numb>r: 


fT.u  IIM.M.I  U 


lEUkll 


Soon«oflna  Authorit 


Cla«a  of  Graphical  Item;  |  LiNEP<Pg 


Nama:  I  breaK  line  -  stvie  2 


A  break  line  linestyle  consists  of  either  one  of  two  allowable  representations  as  specified  m  ANSI  Yf4  2M-i979 

(Line  conventions  and  Lattenng.)  This  is  a  line  consisting  of  long  dashes  joined  by  zigzags. 

1 

This  linetype  is  intended  for  use  m  engineering  drawings. 

Specific  details  are  implementation  dependent.  The  appearance  of  the  degenerate  case  is  implementation 

1 

dependent. 

■ 

Such  a  line  has  the  following  visual  appearance: 

1 

Additional  Commenta 


The  requirements  stated  m  ANSI  yi4.2M-t979  sbail  be  loUowed  wnen  rendering  this  imetype. 
This  linetype  is  not  intended  to  be  used  as  an  edgetype. 


Justification  tor  Inclusion 


This  linetype  is  commonly  used  m  engineenng  drawings.  It  s  one  of  a  set  of  imetypes  registered  ‘or  use  «i; 
computer  graphics  standards  to  enable  compact  storage  and  transfer  of  engineering  drawings. 


Relatlonshl 


t)  ISO  7942  (GKS)  -  Specifies  a  registered  linetype  to  supplement  those  defined  m  5  4  i 

2)  ISO  8632  (COM)  -  Specifies  a  regts’ered  linetype  to  supplement  those  defined  m  5.7  2. 

3)  ANSI  Y14  2M-1979  -  Line  Conventions  and  Lettering, 
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FIGURE  11:  Examples  of 
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Custodians : 

Army  -  CR 
Navy  -  SH 
Air  Force  -  24 
DLA  -  DH 

Review  activities: 

Army  -  AM 
Air  Force  -  01,02 
NSA  -  NS 
DCA  -  DC 
NASA  -  NA 

Others  -  NBS,  DOE,  GPO,  NCS 

TTeAT*  1  x/i  ^  1  * 
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Navy  -  AS,  EC,  OS,  SA,  YD 
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Preparing  Activity 
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EXTENDED  CGM  MILSPEC  PLANNING 


I.  PURPOSE 

Represent  and  inject  CALS  requirements  in  the  standards  efforts 
for  the  Extended  CGM,  or  CGEM.  Plan  for  development  of  a  CGEM 
MILSPEC  (CALS  SOW  Task  3. 1.2. 4). 

This  work  was  accomplished  through  a  contractor,  Mr.  Lofton 
Henderson,  of  Henderson  Software,  who  is  a  member  of  the 
following: 

o  the  Accredited  National  Standards  Committee  X3H3  on 
Computer  Graphics  Staindards; 

o  the  sub-committee,  X3H3.3,  Computer  Graphics  Metafile, 
and  Computer  Graphics  interface  (CGI) ; 

o  the  U.S.  delegation  to  the  International  Standards 

Organization  Working  Group  2  (ISO/WG2)  ,  Computer 
Graphics  Standards; 

o  the  IS0/WG2  CGM  Rapporteur  Group,  responsible  for 

processing  comments,  refining  the  standard,  and  issuing 
interpretations  of  the  standard;  and 

o  the  IS0/WG2  sub-group  developing  the  Extended  Metafile 
standard . 

As  is  apparent,  Mr.  Henderson  is  in  a  unique  position  to  ensure 
that  CALS  requirements  get  addressed  and  injected  into  the 
extended  metafile  (CGEM)  work  at  the  national  and  international 
levels.  He  will  be  referred  to  in  the  remainder  of  this  report 
as  the  MIST  representative,  which  serves  to  properly  identify  -he 
ole  that  he  has  played  in  furthering,  under  NIST  (the  National 

institute  of  Standards  and  Technology,  formerly  NBS)  direction, 

the  needs  of  CALS  in  the  development  of  CGEM. 

[NOTE:  Please  consult  the  GLOSSARY  on  pages  19  and  20  of  this 

report  for  any  acronyms  that  are  unfamiliar. ] 
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II. 


BACKGROUND 


1 . 0  Introduetion 

This  task  was  being  pursued  primarily  at  the  working  meetings  of 
the  graphics  and  metafile  experts  of  ANSI  and  ISO.  In  addition, 
there  was  some  significant  work  between  meetings,  preparing  and 
pulling  together  position  papers,  baseline  standards  documents, 
and  input  documents  to  key  meetings.  The  final  report  of  the 
1987  predecessor  of  this  project  mentioned  briefly  the  ANSI 
meeting  at  Lowell,  MA  in  October  1987.  This  report  covers 
activities  subsequent  to  the  Lowell  meeting. 

The  major  emphasis  of  this  task  is  on  the  CGM  addenda.  There  has 
been  some  work  on  the  related  Graphical  Registration  proposals  as 
well. 


1 . 1  Motivation 

One  consequence  of  the  consensus  process  for  making  the  CGM 
standard  is  that  the  standard  tended  toward  being  a  "least  common 
denominator"  metafile  for  the  various  constituents.  It  is,  to  a 
large  degree,  the  area  of  overlap  that  all  participants  in  its 
formulation  agreed  should  be  in  a  graphical  metafile.  As  a 
result,  it  is  relatively  lean  in  functionality. 

This  expedited  processing  of  the  standard.  However,  CGM  could  be 
more  efficient  in  some  application  environments.  The  CALS 
application  areas  of  technical  illustration,  technical 
publications,  and  compound  document  exchange  are  such 
environments . 

An  extension  process  was  immediately  commenced  to  extend  CGM 
functionality  as  required  by  more  advanced  metafile  applications. 


1 . 2  Historical  Review 

Two  addenda  were  officially  commenced  in  ISO; 

Addendum  1:  intended  to  support  the  GKSM  requirements  of 
GKS,  and  replace  the  non-standard  specification  in 
annex  E  of  GKS ; 

Addendum  2;  intended  to  support  the  metafile  requirements  of 
GKS-3D,  and  replace  the  non-standard  annex  E  of  GKS-3D. 

Due  in  part  to  the  efforts  and  success  of  the  1987  predecessor  of 
this  project,  during  1987: 
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-  The  scope  of  Addendum  1  was  expanded  to  support  some  of 
the  advanced  requirements  of  CALS  (and  similar 
constituencies) :  symbol  libraries,  additional  geometric 
primitives,  and  basic  raster  primitives.  The 

functionality  was  taken  from  and  was  compatible  with 
CGI; 

"Addendum  3"  was  commenced,  to  extend  CGM  further  as 
required  by  the  technical  illustration  and  publishing. 

In  early  1987  the  NIST  representative  worked  within  ANSI  to 
generate  domestic  support  for  such  extensions.  These  positions 
were  then  taken  input  into  the  ISO  meetings.  The  results  were; 

o  acceptance  of  broadening  the  scope  of  Addendum  1  as 
detailed  above; 

o  rejection  (or  postponement)  of  commencing  work  on 
Addendum  3 . 

While  there  was  considerable  support  for  the  concepts  of  Addendum 
3,  there  were  procedural  objections  and  some  disagreement  over 
what  group  should  do  the  work  and  when. 

This  put  the  responsibility  for  the  initiative  on  Addendum  3  back 
into  the  U.S.  standards  group,  ANSI  X3H3.  The  final  activity  of 
this  project  in  1987  was  at  the  NIST/Eurographics  workshop  at 
Gaithersburg,  MD,  in  September  1987.  At  this  meeting  a  sub-group 
studied  the  requirements  of  CALS  and  similar  technical 
constituencies.  The  following  list  summarized  the  requirements 
which  were  identified: 

1.  Internal  symbol  libraries; 

2.  Reference  to  and  invocation  of  pre-defined  external 
symbol  libraries; 

3.  Advanced  geometric  drawing  capabilities,  including: 

user  defined  line type; 
user  defined  hatch  style; 
a  number  of  additional  linetypes; 
a  number  of  additional  hatch  styles; 
several  types  of  spline  curves; 
conics  and  conic  arcs; 
closed  figure  primitive; 
arbitrary  clipping  boundary; 

4.  a  number  and  variety  of  fonts; 

5.  a  completely  new  text  model  based  on  the  work  of  ISO 
9541; 
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6.  additional  raster  primitives  (and  associated  attributes 
for  image  processing) ; 

Shortly  thereafter  the  metafile  sub-group  of  X3H3.3  met  and 
produced  the  following  for  input  to  the  initial  SC24  meeting  at 
Berlin  in  December  1987; 

o  A  statement  of  need,  scope  and  purpose  for  Addendum  3; 

o  A  baseline  docxment  for  the  functionality  of  Addendum 

3,  in  the  style  of  Clause  5  of  CGM  Part  1  (abstract 
specification  of  the  foinctions  in  Addendum  3)  . 


In  overview,  in  1987  this  project; 

o  organized  ANSI  support  for  the  CGM  extensions  required 
for  CALS; 

o  accomplished  some  of  these  extensions  in  the  context  of 
CGM  Addendum  1; 

o  brought  Addendum  3  for  the  first  time  into  the  ISO 
arena ;  and 

o  produced  the  groundwork  (the  requirements  statement) 
for  progressing  Addendum  3  in  ANSI  and  ISO. 
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III.  DISCUSSION 


1.0  Project  Progress  in  1988 

The  goals  for  this  CALS  CGEM  task  were: 

1.  Acceptance  of  the  Addendum  3  project  by  ISO.  Pursuing  it  as 
purely  an  ANSI  project,  and  doing  it  on  the  fast  track,  was 
discussed.  However  there  is  significant  enough  interest  in 
ISO  that  an  ISO  project  would  likely  be  initiated  before 
such  an  ANSI  project  could  complete.  Past  experience 

.  indicates  that  ANSI  would  not  likely  approve  the  content  of 
Addendum  3  as  an  ANS  if  there  were  an  active  ISO  project  and 
if  there  were  a  chance  of  incompatibility  between  the  two. 
Hence  proceeding  without  ISO  in  this  case  risked  the  waste 
of  significant  effort,  and  ultimately  the  slowing  down  of 
the  project. 

2.  Production  of  scope  and  purpose  documents,  and  a  reasonably 
complete  baseline  document  for  the  Addendum  3  functionality. 
In  the  worst  case,  it  was  necessary  to  be  prepared  to 
proceed  with  standardization  if  ISO  dragged  on  the  project. 

3.  Circulation  of  Addendum  1  PDAD  or  Proposed  Draft  Addendum 
(see  the  Glossary)  text  in  ANSI  and  generation  'of  a  U.S. 
position  on  the  ISO  PDAD  ballot.  There  were  two  si:b-goals 
here:  insure  that  Addendxim  1  was  processed  rapidly  and 
smoothly;  watch  over  the  "CALS  content"  of  Addendum  1  and 
insure  that  it  remained  intact. 

4.  Generation  of  some  U.S.  position  on  the  30  Addendum  2. 
There  has  been  relatively  little  interest  in  this  in  the 
U.S.  Still,  it  is  in  CALS  interest  to  see  the  work  go  as 
smoothly  as  possible  so  that  resources  (which  are  scarce) 
are  not  drawn  away  from  CALS  priorities  excessively. 


2.0  Key  Meetings  of  1987-88 


2.1  The  Berlin  SC24  Meeting 

This  was  the  first  meeting  of  the  SC24  Plenary.  Between  October 
and  December  a  baseline  document  for  the  functional  content  of 
Addendum  3  was  produced  by  the  X3H3.3  metafile  specialists.  A 
draft  of  the  functional  content  was  produced  as  input  to  the 
Berlin  meeting.  Copies  of  the  scope  and  purpose  document  and 
that  of  the  baseline  functional  specification  are  in  Appendix  1 
of  this  report. 

The  goal  at  the  Berlin  meeting  was  to  get  Addendum  3  accepted  as 
an  ISO  project  and  assigned  to  the  WG3  Metafile  Rapporteurs  Group 
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(MRG)  .  The  input  documents  were  tentative,  but  they  were 
primarily  intended  to  demonstrate  serious  interest,  progress,  and 
willingness,  to  do  the  work.  The  Berlin  meeting  was  not  attended 
by  any  of  the  X3H3.3  CGM  experts,  but  Peter  Bono  presented  and 
represented  the  U.S.  positions. 

SC24  did  not  accept  and  initiate  a  project  for  Addendum  3. 
Instead  two  things  of  significance  happened.  It  voted  to 
circulate  the  documents  for  comment  as  a  New  Work  Item  (NWI) 
proposal.  It  set  up  a  Special  Working  Group  on  Future  Planning 
(SWG/FP)  to  study  current  SC24  projects  and  procedures,  make 
recommendations,  and  recommend  future  projects. 

There  were  several  sources  of  opposition  to  initiating  a  fast 
project  on  the  functional  content  of  Addendum  3; 

1.  Some  maintained  that  it  was  procedurally  inappropriate  to 
continue  to  initiate  work  as  extensive  as  Addendum  3 . 
Rather,  the  ISO  NWI  procedures  should  be  followed; 

2.  There  was  sentiment,  based  on  a  certain  reference  model  of 
computer  graphics,  that  such  significant  functional 
extension  cannot  be  standardized  in  the  metafile  without 
first  standardizing  it  in  the  API  (Application  Programmer 
Interface)  standards  such  as  GKS.  This  reference  model 
purports  that  standard  metafiles  can  only  be  generated 
through  standard  interfaces,  and  cannot  (for  example)  be 
used  to  transfer  pictures  in  a  standard  manner  to/ from 
proprietary  CAD  systems. 

3.  There  is  reluctance  to  allow  the  MRG  experts  alone  to  design 
significant  functional  extensions  (splines,  conics,  text, 
etc.)  that  may  in  the  future  be  included  in  other  standards. 
According  to  this  point  of  view,  such  functionality  really 
belongs  to  the  "next  generation"  of  graphics  standards  and 
should  have  wider  participation  in  its  formulation. 

The  results  of  the  Berlin  meeting  were  disappointing  in  that 
Addendum  3  was  not  accepted  for  progression.  It  was  hoped  that 
the  Salt  Lake  ANSI  meeting  (January  1988)  might  be  used  as  the 
first  ISO  working  meeting  on  Addendum  3,  with  international 
members  of  the  MRG  attending.  On  the  other  hand,  the  results 
were  encouraging  in  that  the  SWG/FP  seemed  to  present  an 
opportunity  to  get  the  work  endorsed  and  initiated. 


2.2  The  Salt  Lake  Meeting 

In  December  the  PDAD  text  of  Addendum  1  was  received  in  the  U.S. 
from  the  document  editor  (Anne  Mumford)  in  England  and  the  ISO 
PDAD  ballot  (3  months)  was  commenced.  The  document  was 
circulated  to  X3H3.  There  was  not  time  to  have  a  letter  ballot 
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before  Salt  Lake. 


Because  all  open  technical  Issues  had  been  resolved,  and  because 
the  PDAD  dO'.-!ument  was  supposed  to  reflect  these  resolutions,  the 
position  taken  was  that  the  U.S.  response  was  a  matter  of 
verifying  that  the  docvuaent  did  in  fact  reflect  the  resolutions. 
Consequently,  because  there  were  no  unresolved  technical  issues, 
it  was  concluded  that  a  working  group  of  metafile  experts  could 
prepare  the  response  at  Salt  Lake,  and  ask  X3H3  plenary  to 
approve  it . 

In  fact  the  U.S.  response  Ccune  to  over  25  pages  and  its 
production  consumed  the  entire  Salt  Lake  meeting.  A  copy  of  the 
Addendum  1  PDAD  text  is  in  Appendix  2  of  this  report,  and  the 
U.S.  response  dociiment  is  in  Appendix  3.  There  were  no  serious 
technical  problems  with  the  Addendum  1  PDAD  text.  The  technical 
issues  had  been  resolved  in  1987  in  a  manner  satisfactory  to  the 
U.S.  (and  CALS) .  Rather,  there  were  extensive  editorial  problems 
and  minor  technical  issues. 

The  most  pervasive  problems  derived  from  the  relationship  of 
Addendum  1  to  CGI  (most  of  the  technical  material  was  lifted  from 
CGI)  .  These  problems  were  twofold.  Firstly,  some  CGI 
functionality  changed  at  Valbonne  and  at  an  editing  meeting  a 
couple  months  later,  but  it  was  not  possible  to  obtain  new  CGI 
text  until  mid-1988.  The  CGM  Addendum  1  document  editor  had  to 
make  do  with  the  old  text.  Secondly,  much  of  the  text  (e.g., 
segmentation)  was  lifted  almost  verbatim  from  CGI.  While  the 
text  was  appropriate  for  a  procedural  interface,  it  was  not 
appropriate  for  a  graphical  database  definition  such  as  CGM. 

Finally,  there  were  numerous  problems  that  were  oversights, 
omissions,  etc.  The  only  really  significant  new  material  that 
the  Salt  Lake  review  turned  up  had  to  do  with  the  Formal  Grammar. 
For  the  first  time  in  several  years  there  was  a  specialist  on 
hand,  and  he  detected  a  number  of  problems  both  with  the  Addendum 
text  and  the  original  CGM  standard. 

The  response  document  was  approved  as  planned  by  X3H3  plenary, 
and  was  sent  to  ANSI  during  February  for  forwarding  to  ISO. 
Although  the  U.S.  had  no  serious  objections  to  PDAD  1,  it  was 
voted  "no”.  This  is  a  procedural  requirement  of  ANSI  if  any  of 
the  comments  are  technical,  then  the  vote  must  be  "no'.  The  "no" 
vote  is  reversed  at  the  ISO  meeting  when  the  technical  comment  is 
resolved  to  the  satisfaction  of  the  U.S.  delegation. 

A  final  significant  result  at  Salt  Lake  is  that  the  NIST 
representative  was  selected  as  one  of  the  two  U.S.  delegates  for 
the  SWG/FP  meeting  (see  below) . 
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2.3  About  Addendum  2 


There  was  an  Addendum  2  (3D)  working  meeting  in  England  in 
November,  attended  only  by  U.K.  and  Germany.  Revised  Addendum  2 
text  was  supposed  to  be  received  by  early  February.  The  Berlin 
SC24  meeting  had  resolved  that  the  text  should  be  circulated  as  a 
Working  Draft,  for  a  comment  period  that  expired  in  April.  The 
Salt  Lake  X3H3  empowered  an  ad  hoc  group  to  meet  and  prepare  a 
U.S.  response.  This  meeting  was  planned  to  occur  at  the  NCGA  '88 
expo  in  late  March.  In  fact,  the  document  was  not  received  until 
the  day  before  NCGA.  There  was  no  time  to  prepare  a  response,  so 
the  U.S.  requested  an  extension  of  the  comment  period. 

When  the  Addendum  2  WD  text  arrived,  the  minutes  of  the  meeting 
in  England  had  still  not  been  received  and  there  was  little  idea 
what  to  expect.  The  text  that  arrived  was  significantly  broader 
in  scope  than  what  had  been  resolved.  Instead  of  minimal  support 
for  GKS-3D,  there  was  added  support  for  a  PHIGS  MO  workstation 
and  even  a  replacement  for  the  PHIGS  archive  file.  The  X3H3.3 
metafile  group,  of  which  the  NIST  representative  is  a  member, 
tended  to  not  have  strong  positions  on  3D,  but  the  group  knew 
there  would  probably  be  some  strong  feelings  in  X3H3.1  (the  PHIGS 
sub-group).  Therefore,  the  X3H3.3  group  circulated  the  document 
to  X3H3.3  and  X3H3 . 1  and  arranged  for  a  joint  ad-hoc  group  to 
prepare  the  U.S.  response  at  the  Fairfax  X3H3  meeting  (May  1988) . 

This  radical  change  of  scope  of  Addendum  2  turned  out  to  be  one 
of  the  triggering  events  for  work  at  Fairfax  and  Tucson  (SC24, 
July  1988)  which  changed  the  fundamental  structure  and  direction 
of  the  addendum  work. 


2.4  The  Blakeney  SWG/FP  Meeting 

For  some  time  there  had  been  dissatisfaction  within  SC24  (and  its 
predecessor  SC21/WG2)  over  the  state  and  process  of  making 
graphics  standards.  In  particular: 

o  the  process  takes  much  too  long; 

o  there  is  insufficient  coordination  among  projects  that 
are  supposed  to  be  closely  related; 

o  there  is  lack  of  an  overall  reference  model  explaining 
the  relationships  between  the  standards. 

The  list  goes  on  with  a  number  of  other  points.  Coupled  with 
this  dissatisfaction,  there  was  sentiment  within  SC24  to  shelve 
CGI  (it  was  taking  too  long  and  had  missed  its  "window  of 
opportunity")  and  demands  for  a  number  of  new  standards  and 
extensions  even  before  work  on  the  "first  generation"  of 
standards  was  complete.  These  new  project*  included: 
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1.  CGM  Addendxun  3; 

2.  PHIGS  extensions  {PHIGS+) ; 

3.  Windowing  standards; 

4 .  Imaging  standards ; 

5.  GKS  review  and  revision; 

In  order  to  sort  out  these  competing  demands  the  Berlin  SC24 
meeting  established  a  Special  Working  Group  on  Future  Planning. 
Each  national  body  was  allowed  to  send  two  representatives.  The 
NIST  representative  was  selected  to  be  one  of  the  U.S. 
representatives.  This  looked  to  be  an  excellent  strategic 
outcome  for  Addendxim  3  constituents,  which  includes  the  CALS 
constituency,  because  it  was  expected  that  the  SWG/FP  would  deal 
specifically  with  new  proposals  such  as  Addendum  3.  Our  NIST 
representative  was  thus  in  a  good  position  to  influence  the 
progress  and  acceptance  of  Addendum  3  as  an  ISO  project. 

In  fact,  during  the  3 -day  meeting  (11-13  April)  it  was  never 
possible  to  pull  the  attention  of  the  SWG/FP  down  to  the  level  of 
talking  about  specific  projects.  Instead  there  was  considerable 
discussion  of: 

o  "lessons  learned"; 

o  a  recognition  of  the  distinction  between  first  and 
second  generation  standards; 

o  a  determination  that  first  generation  standards  must 

finish  quickly  (within  a  year) ;  and 

o  a  determination  that  all  new  work  must  be  structured 
differently. 

The  IEEE  Computer  Graphics  and  Applications  magazine  article  by 
G.S.  Carson  provides  an  excellent  summary  of  this  meeting. 
Rather  than  repeat  that  material,  the  article  is  included  in 
Appendix  4.  In  Appendix  5  is  a  copy  of  the  5-year  plan  that  is 
referenced  in  the  article. 

CGM  Addenda  1  &  2  were  considered  to  be  first  generation 

standards,  and  were  encouraged  to  complete  work  rapidly.  At  the 
same  time  it  was  recognized  that  Addendum  2  was  in  some  trouble, 
as  there  was  widespread  dissatisfaction  over  the  change  of  scope 
and  apparent  confusion  of  purpose — there  was  skepticism  that  it 
could  reach  DIS  stage  in  the  1-year  period  before  the  cutoff, 
given  that  it  had  not  even  managed  to  reach  an  agreed  scope  yet. 
The  U.S.  (and  CALS)  would  not  have  minded  work  being  suspended  on 
Addendum  2,  since  it  is  perceived  as  draining  scarce  resources 
that  could  be  used  on  Addendum  3. 

Addendum  3  was  officially  considered  to  be  a  second  generation 
standard.  The  NIST  representative  observed  a  reluctance  to  deal 


9 


with  it.  This  was  for  the  reasons  discussed  above  (the  Berlin 
SC24  meeting) .  There  was  also  some  sentiment  from  GKS  advocates 
that  the  work  belonged  in  GKS  extension  and  review.  There  was 
the  already  mentioned  philosophical  objection  that  functionality 
could  not  be  included  in  a  metafile  standard  that  did  not  have 
correspondence  in  an  API  (Application  Programmer  Interface) 
standard . 

In  term  of  officially  results,  then,  SWG/FP  did  little  for 
advancing  Addendum  3.  Unofficially,  however,  there  was  some 
productive  exchange  with  other  national  delegates.  The  NIST 
representative  was  able  to  communicate  two  points  in  particular: 

1.  The  real-world  experience  gained  in  the  multi-vendor  CGM 
system  integration  demonstration  at  NCGA's  Integrate  '88  was 
used  as  evidence  for  the  U.S.  position  that  a  metafile 
standard  is  not  only  used  just  by  stsuxlarcl  application 
systems,  and  can  have  functionality  not  seen  in  such 
systems.  At  Integrate  *88  it  is  estimated  that  not  more 
than  1/3  of  the  CGM  generating  and  interpreting  systems 
involved  other  ISO  graphics  standards.  Rather,  CGM  modules 
were  attached  to  existing  proprietary  systems,  such  as  CAD 
systems.  Some  key  objectors  to  Addendum  3  privately 
admitted  that  this  view  of  metafile  utilization  had  merit. 

2.  It  was  not  concealed  that  the  U.S.  would  proceed  on  the 
standardization  of  Addendum  3  if  ISO  did  not  demonstrate 
interest  in  expediting  such  work.  It  was  the  U.S.  position 
that  the  normal  5-year  timeframe  is  much  too  long  to  wait 
for  this  work.  The  extensions  are  needed  now. 

By  the  time  of  the  Tucson  meeting  there  appeared  to  be  some 
acknowledgement  of  these  points.  The  NIST  representative  thought 
that  the  unofficial  exchanges  at  Blakeney  had  some  effects.  The 
work  of  the  SWG/FP  and  subsequent  national  body  contributions 
formed  the  framework  and  defined  the  agenda  for  that  meeting. 


2.5  The  Blakeney  Metafile  RG  Meeting 

In  the  week  following  the  SWG/FP  meeting  there  was  a  3-day  (18-20 
April)  WG3  Metafile  Rapporteur  Group  (MRG)  meeting  at  the  same 
location  in  Blakeney,  England.  The  purpose  of  the  meeting  was 
twofold:  firstly,  the  PDAD  ballot  on  Addendum  1  was  complete  and 
those  results  had  to  be  processed;  secondly,  it  was  planned  to 
process  WD  comments  on  Addendvun  2  and  prepare  to  advance  the  text 
to  PDAD  stage. 

The  meeting  was  not  officially  empowered  as  an  editing  meeting, 
so  could  not  produce  official  response  document.  Rather  the 
output  would  be  input  to  the  official  MRG  editing  meeting  at 
Tucson.  In  reality,  since  the  active  metafile  experts  from  the 
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most  important  delegations  were  present,  it  was  anticipated  that 
the  work  would  be  endorsed  mostly  intact  at  Tucson.  The  meeting 
was  sparsely  attended;  1  U.S.  (NIST  representative),  3  U.K.  (but 
only  2  present  at  any  given  time) ,  and  2  Germany. 

The  time  allocated  for  the  two  addenda  was  1  day  for  PDAO  Add.l 
comments,  and  2  days  for  refining  Add. 2.  We  (the  U.S.)  objected 
that  2  days  was  too  much  for  Addendum  2  the  docviment  had  only 
been  circulated  3  weeks  before  and  none  of  the  national  comments 
were  in  hand.  It  was  also  pointed  out  that  it  was  known  that 
there  were  objections  from  several  nations  over  the  expansion  and 
confusion  of  scope.  It  was  agreed  to  spend  more  time  on  Addendum 
1,  spend  an  afternoon  explaining  and  discussing  Addendiim  2,  and 
spend  the  last  day  finishing  off  any  issues  on  Addendum  1  and 
drafting  output  documents  on  both  addenda. 

The  PDAD  ballot  drew  5  negative  votes,  including  France,  Germany, 
U.K. ,  U.S.  (see  "Salt  Lake  Meeting”),  and  Czechoslovakia.  Most 
of  the  objections  were  similar  to  those  of  the  U.S.,  including 
especially  concern  over  the  reliance  on  CGI,  which  was  perceived 
to  be  unstable.  The  MRG  response  on  that  point  was  basically:  in 
consequence  of  the  SWG/FP  work,  CGI  must  either  be  technically 
stable  now  or  it  won't  become  a  standard.  If  Add.l  is  simply 
made  current  with  CGI,  then  CGM  should  be  stable  in  those  areas 
of  overlap. 

As  with  the  U.S.  response,  other  national  responses  contained 
many  minor  technical  points.  In  fact  it  took  all  of  the 
allocated  time  plus  some  to  sort  through  the  points  and  come  to 
consensus  on  the  important  ones.  Some  were  stacked  for  Tucson. 
From  the  CALS  point  of  view,  nothing  significant  happened  at  this 
meeting  (which  was  just  what  was  wanted — stability  of  the 
extended  functionality  which  was  important  to  CALS) .  There  was 
some  move  to  remove  PIXEL  ARRAY  (an  element  needed  by  CALS) 
because  of  alleged  changes  in  CGI.  This  discussion  was  postponed 
for  Tucson.  Aside  from  important  functionality  remaining  intact, 
the  proposed  Addendum  1  schedule  was  the  only  other  topic  of 
importance  to  CALS;  the  MRG  agreed  to  attempt  an  aggressively 
fast  schedule — produce  DIS  text  at  Tucson  and  try  for  IS  text  in 
summer  1989. 

There  was  no  significant  time  available  or  allocated  for  Addendum 
3 .  The  best  that  could  be  achieved  at  this  meeting  was  a  weakly 
worded  recommendation  from  the  MRG  to  SC24  that  the  work  is 
important  and  should  be  progressed  (possibly  by  experts  from 
several  areas  in  addition  to  metafiles) .  This  did  serve  to  keep 
the  topic  alive  and  visible.  But  overall,  the  two  Blakeney 
meetings  did  not  produce  any  definitive  new  results  for  Addendum 
3. 

Appendix  6  contains  selected  documents  from  the  Blakeney  MRG 
meeting.  Included  are  the  minutes,  the  explanation  of  Addendum 


11 


2,  and  a  summary  of  voting  on  PDAO  Addendum  1. 


2.6  The  Fairfax  X3H3  Meeting 

Attempts  to  persuade  ISO  to  immediately  commence  work  on  Addendum 
3,  and  assign  it  to  the  WG3  metafile  rapporteur  group,  had  not 
achieved  positive  results  at  the  Berlin  and  Blakeney  meetings. 

It  was  the  U.S.  position  that  the  U.S.  would  proceed  if  a  project 
were  not  taken  up  by  ISO.  The  purpose  of  proceeding  within  the 
U.S.  was  twofold:  firstly,  the  constituency  for  Addendum  3  (e.g. , 
CALS)  needed  the  functional  extensions  without  undue  delay; 
secondly,  ISO  did  apparently  intend  to  take  up  the  work  sooner  or 
later,  in  some  form.  ISO  would  likely  take  it  up  sooner  if  the 
U.S.  continued  to  progress  Addendum  3  as  a  domestic  U.S. 
standard,  and  the  subsequent  technical  work  would  proceed  faster 
as  well. 

At  the  Fairfax  meeting,  then,  the  metafile  sub-group  had  two 
goals  with  regard  to  Addendum  3.  The  first  was  to  produce  a  new 
revision  of  the  baseline  document  for  Addendum  3.  The  second  was 
to  produce  a  draft  SD-3  for  an  X3H3  Addendum  3  project.  An  SD-3 
is  the  statement  of  scope,  purpose,  and  need  which  is  used  to 
initiate  a  standards  project  in  one  of  the  accredited  ANSI 
committees.  The  SD-3  was  to  be  circulated  during  the  summer  for 
an  approval  ballot  within  X3H3.  Approval  would  basically  give 
the  project  the  standing  of  an  official  ANSI  project  (after  some 
higher  approvals  in  X3) . 

The  two  documents  were  also  intended  for  circulation  within  ISO. 
Again  the  purpose  was  twofold:  to  demonstrate  that  the  U.S.  was 
serious  about  the  need  for  the  project,  was  ready  to  supply  the 
necessary  resources,  and  was  willing  and  capable  of  proceeding 
alone;  and  to  keep  ISO  metafile  experts  current  so  that  a 
transition  could  be  effected  smoothly  should  ISO  commit  to  doing 
Addendum  3 . 

Some  of  the  work  to  refine  and  extend  the  draft  document  was  done 
by  interim  assignments  before  Fairfax.  The  rest  was  done  at 
Fairfax  and  in  working  assignments  during  the  following  month. 
The  result  is  contained  in  Appendix  7.  A  draft  of  the  SD-3  was 
produced  at  the  meeting.  The  metafile  sub-group  would  have  liked 
to  be  able  to  refine  the  drafts  somewhat  more,  and  to  get  more 
group  discussion  and  issues  resolution.  Lack  of  time  and  staff 
was  a  problem. 

There  were  10  people  available  to  work  at  Fairfax.  It  turned  out 
that  the  NIST  representative  and  one  other  had  to  work  most  of 
the  three  days  on  other  matters. 

One  of  the  items  on  the  agenda  at  the  meeting  was  to  form  a  U.S. 
position  on  Addendum  2,  3D.  There  was  significant  unhappiness 
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with  the  draft  which  had  been  received  from  England  in  March.  It 
had  significantly  expanded  in  scope,  to  the  point  where  it 
concerned  U.S.  3D  experts  (PHIGS) .  More  importantly,  a  number  of 
U.S.  experts  within  X3H3  were  concerned  with  attaching  the 
functionality  of  Addendxim  2  and  the  G’^S  audit  trail  portion  of 
Addendum  1  to  the  CGM  standard.  Regardless  of  the  merits  of  the 
material,  its  nature  is  contrary  to  the  basic  philosophy  of  the 
static  picture  capture  CGM.  Within  the  U.S.  there  was  a 
significant  constituency  which  appreciated  what  the  CGM  was  and 
found  it  useful  and  appropriate. 

A  liaison  meeting  was  scheduled  to  work  with  the  3D  experts  to 
formulate  a  U.S.  position  on  Addendiom  2.  In  fact,  the  output  of 
the  meeting  was  the  production  of  a  basic  Metafile  Reference 
Model  (MRM)  which  demonstrated  why  the  U.S.  was  dissatisfied  with 
what  was  happening  in  the  addendum  process.  The  MEUi  shows: 

1.  there  can  be  metafiles  defined  at  any  level  in  a  graphical 
hierarchy;  and 

2.  the  metafiles  can  either  be  static  (snapshot)  in  nature,  or 
they  can  be  dynamic  (session  capture) .  The  former  are  a 
snapshot  of  the  state  of  some  layer  in  the  hierarchy,  while 
the  latter  are  an  audit  trail  of  the  dialogue  over  some 
interface  in  the  model. 

According  to  the  MRM  the  CGM  is  a  static  picture  capture  metafile 
at  the  level  of  the  virtual  device.  The  GKSM  content  of  Addendum 
1,  however,  is  at  a  higher  level  in  the  model  and  is  a  session 
capture  specification.  Similarly,  several  distinct  metafiles 
were  identified  in  the  draft  Addendum  2 — all  were  of  a  different 
nature  (dynamic)  or  at  a  different  level  than  CGM  in  the  MRM. 

This  model  was  refined  and  approved  by  X3H3  for  input  to  the 

Tucson  meeting  as  a  U.S.  position  (see  Appendix  8)  .  The  model 
i^ecame  the  basis  for  U.S.  objections  to  Addendum  2,  and  was  the 
basis  for  a  proposal  that  Addendum  1  be  split.  The  static 

portion  of  Addendum  1  (the  portion  of  interest  to  CALS)  would 

continue  to  be  progressed  as  an  addendum  to  CGM.  The  audit  trail 

portion  would  progress  as  an  addendum  to  GKS.  According  to  the 
MRM,  Addendum  3  was  in  the  spirit  of  CGM  and  should  properly  be 
progressed  as  an  addendum  to  CGM.  This  is  contrary  to  several 
opinions  which  were  being  heard  in  the  ISO  community. 

Although  an  unexpected  result,  the  MRM  and  the  position  papers  on 
the  addenda  which  derived  from  the  MRM  were  by  far  the  most 
important  output  of  the  Fairfax  meeting  and  had  the  most  far- 
reaching  implications. 


13 


2.7  The  Tucson  SC24  Meeting 

The  MRM  and. associated  position  papers  were  pre-circulated  to  key 
members  of  the  metafile  rapporteur  group  prior  to  Tucson.  Some 
of  the  other  national  delegations  were  having  similar  problems 
with  the  CGM  addenda,  and  so  the  time  was  ripe  for  a  proposal 
that  made  some  sense  of  the  disorder.  There  was  interest  in  the 
U.S.  proposals. 

At  the  Tucson  meeting  itself,  the  MRM  and  the  U.S.  proposals  for 
restructuring  the  CGM  work  were  endorsed  in  the  first  half  of  the 
first  day.  The  rest  of  the  meeting  was  basically  concerned  with 
implementing  the  new  structure,  working  out  technical  issues,  and 
working  out  procedural  problems  and  schedules.  A  detailed  report 
of  the  activities  at  Tucson  is  contained  in  Appendix  9. 

To  summarize  the  practical  effects  of  the  Tucson  resolutions  (see 
Appendix  10  for  the  complete  resolutions  text) : 

o  the  static  picture  content  of  Addendum  1  continues  to 
be  progressed  as  an  addendum  to  CGM.  It  is  known  as 
the  static  structured  picture  capture  (SS?C)  metafile. 
It  contains  everything  from  addendum  1  that  is 
important  to  CALS.  It  is  known  as  CGM  Add.l. 

o  the  dynamic  session  capture  content  of  Addendum  l  is 
removed  and  progressed  separately  as  an  addendum  to 
GKS,  known  as  GKS  Add.l.  The  timetable  is  to  be  the 
same  as  that  for  CGM  Add.l.  There  is  nothing  in  GKS 
Add.l  that  is  of  much  importance  to  the  CALS 
constituency. 

o  the  static  content  of  Addendum  2  will  be  progressed  as 
an  addendum  to  CGM,  known  as  CGM  Add.  2.  It  will 
represent  static  3D  pictures.  There  are  some 
interesting  possibilities  for  CALS  in  this  content.  In 
particular,  it  may  be  very  natural  to  translate  IGES 
and  PDES  into  CGM  Add. 2  (or  Add. 2  extended  with 
advanced  geometric  primitives) . 

o  the  dynamic  content  of  Addendum  2  will  be  removed  and 
progressed  as  an  addendum  to  GKS-3D,  known  as  GKS 
Add. 2. 


About  Addendum  3:  WGl  (reference  models,  user  requirements,  etc) 
and  the  Tucson  plenary  passed  resolutions  which  finally  gave 
standing  to  Addendum  3  in  ISO.  It  is  recognized  that  two 
technical  areas  are  critical  to  Addendum  3 :  advanced  text  and 
font  facilities;  and  advanced  geometric  primitives  (splines, 
conics,  etc.).  It  was  also  recognized  that  these  technical  areas 
are  of  key  importance  in  other  SC24  standards  and  standards 
proposals,  such  as  GKS  9x  (the  successor  to  GKS)  ,  PHIGS+,  etc. 
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Accordingly  a  number  of  technology  and  study  groups  were  formed. 
Three  of  these  of  importance  to  CALS  are: 

1.  advanced  text  models; 

2.  product  data  geometry; 

3.  CGM  extensions. 

The  third  group  is  essentially  an  Addendum  3  study  group.  It  is 
to  meet  in  parallel  with  the  technology  groups,  decide  whether  a 
New  Work  Item  is  desirable,  and  produce  such  and  a  high-quality 
baseline  document  (draft  Addendum  3  standard) .  The  timeframe  for 
completion  of  the  study  and  baseline  document  is  about  one  year. 
The  rapporteur  of  the  metafile  extensions  study  group  is  the  NIST 
representative . 

This  at  last  is  the  positive  commitment  to  Addendum  3  that  was 
sought  from  ISO.  There  may  be  some  negative  aspects  to  the  ISO 
commitment.  Foremost  among  these  is:  how  long  will  it  take  to 
get  the  work  done  in  ISO? 

A  final  consequence  of  the  Tucson  resolutions  was  that  there  was 
no  longer  any  particular  rush  to  produce  the  SD-3  for  Addendum  3 . 
However,  since  final  text  for  CGM  Add.l  was  scheduled  for  summer 
1989,  there  was  now  some  urgency  to  initiate  formal  ANSI 
processing.  This  had  not  been  done  previously,  because  ANSI  is 
in  the  process  of  adopting  new  procedures  which  would  allow  for 
automatic  tracking  and  adoption  of  ISO  standards  work  (without 
having  to  carry  out  parallel  ANSI  work) .  These  procedures  have 
been  very  much  slower  in  coming  than  was  anticipated. 
Accordingly,  the  SD-3  for  Addendum  3  was  converted  to  an  SD-3  for 
CGM  Add.l,  and  this  is  being  voted  now  in  letter  ballot  by  X3H3. 


15 


IV.  SUMMARY  AND  CONCLUSION 


The  1987  predecessor  of  this  task  was  largely  concerned  with 
defining  the  CALS  requirements  for  CGEM,  getting  those 
requirements  endorsed  and  agreed  to  by  both  the  ANSI  and  ISO 
bodies  working  on  the  extensions,  and  getting  work  initiated  on 
the  CALS  extensions.  The  requirements  definition  and  ANSI  X3H3 
endorsement  were  largely  accomplished.  This  task  has  continued 
to  seek  ISO  endorsement  and  status  for  the  project  and  has 
otherwise  focussed  on  producing  draft  documents  containing  the 
required  functional  content. 

Specific  goals  for  1988  were: 

1.  Expedite  processing  of  COM  Addendum  1.  As  a  result  of 
work  in  1987  Addendum  1  contained  a  number  of  functions 
that  were  important  and  useful  to  CALS. 

2.  Get  ISO  approval  for  Addendum  3  as  an  ISO  project, 
assigned  to  the  existing  Metafile  Rapporteur  Group 
(MRG)  ,  and  "fast-tracked”  to  completion.  Most  of  the 
required  CALS  functionality  resides  in  Addendum  3 . 

3.  Coordinate  the  CGEM  work  with  registration  proposals  to 
insure  maximum  compatibility.  While  awaiting  the  more 
permanent  results  from  the  lengthier  CGEM 
standardization  process,  CALS  is  also  pursuing  a  short 
term  strategy  of  submitting  some  of  its  required 
functionality  for  Graphical  Registration. 

For  CGM  Addendum  1,  progress  was  excellent  in  1988.  Addendum  1 
was  sxibmitted  for  its  first  PDAD  ballot  in  1988.  The  U.S. 
submitted  a  25-page  set  of  comments,  participated  in  the 
preliminary  processing  of  the  ballot  results  at  an  interim  ISO 
Metafile  Rapporteur  Group  meeting,  and  participated  in  the  final 
processing  at  the  June  ISO  SC24  meeting.  Between  these  two 
meetings  an  ANSI  X3H3  working  meeting  produced  a  Metafile 
Reference  Model,  which  was  submitted  to  ISO.  This  led  to  a 
complete  restructuring  of  the  work  on  Addendum  1  (and  Addendum  2 
as  well) .  The  static  extended  functionality  and  static  segments 
important  to  CALS  will  continue  to  be  processed  as  an  addendum  to 
CGM,  while  dynamic  functionality  (of  little  use  to  CALS)  will  be 
split  out  and  progressed  as  an  addendum  to  GKS.  Addendum  1  will 
progress  directly  to  DAD  status,  bypassing  an  anticipated  second 
PDAD  ballot.  Assuming  no  unforseen  technical  problems  on  the  DAD 
ballot,  final  text  should  be  available  in  about  1  year. 

No  new  CALS  functionality  was  added  to  Addendum  1,  but  this  was 
neither  intended  nor  desired.  Basically  the  functional  content 
of  this  addendum  was  closed  in  late  1987,  CALS  requirements  were 
included  as  much  as  feasible,  and  the  1988-89  CALS  agenda  for 
Addendum  1  is  to  get  the  processing  completed  as  soon  as 


16 


possible. 

Most  of  tbe  CGM  extensions  needed  by  CALS  are  addressed  in 
Addendum  3.  On  Addendum  3  r  insults  were  mixed.  ANSI  X3H3  has 
endorsed  the  project  and  indicated  willingness  to  pursue  it  as  a 
U.S.  standard  if  ISO  does  not  pick  it  up.  By  mid-year  a  draft  of 
the  required  functional  content  had  been  produced,  complete  with 
Scope  and  Purpose,  Functional  Specification,  and  the  three  data 
encodings.  The  SD-3  had  also  been  prepared,  which  is  the 
document  required  to  give  the  project  official  status  as  an  ANSI 
standards  project.  A  projected  timetable  showed  completion  of 
the  project  in  1990. 

There  has  been  resistance  within  ISO  to  initiating  the  project  as 
an  addend^Jm  to  CGM,  and  this  continued  through  mid-year.  No 
official  endorsement  of  the  project  was  achieved  in  the  first  few 
opportunities.  In  fact  there  was  positive  resistance,  based 
primarily  on  political  and  '•  jurisdiction”  issues.  Finally  at  the 
SC24  meeting  in  June  a  study  group  was  established,  which  should 
lead  to  a  New  Work  Item  and  DP-quality  draft  within  a  year.  This 
is  both  good  and  bad  news.  On  the  positive  side,  ISO  has  now 
given  status  to  the  project,  and  the  study  group  rapporteur  is 
the  NIST  representative.  Thus  CALS  is  in  an  excellent  positions 
to  see  that  its  requirements  are  included  in  the  new  work.  On 
the  negative  side,  the  process  will  probably  be  slower  by  1-1.5 
years  than  if  ANSI  had  proceeded  alone.  It  may  be  3  years  until 
final  tekt  is  available.  In  the  balance,  ANSI  could  probably  not 
have  proceeded  alone  without  getting  overtaken  by  ISO  at  a  later 
date. 
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V. 


RECOMMENDATIONS 


The  CALS  required  content  of  Addendum  1  is  fairly  safe  now,  and 
routine  oversight  of  remaining  Addendum  1  processing  should 
suffice  (the  6-month  DAD  ballot  commences  in  Oct-Nov  1988) .  The 
requirements  study  for  ''Addendum  3"  is  complete  and  draft  text 
has  been  circulated  within  X3H3  for  the  fiinctionality .  However 
the  standard  embodying  this  will  be  an  ISO  standard,  and  its 
scope  and  content  will  be  completely  determined  during  the  next 
12  months.  During  this  period  it  is  critical  for  CALS  to 
continue  to  present  its  requirements.  An  ideal  opportunity  to  do 
so  exists,  as  the  NIST  representative  has  been  approved  to  lead 
the  study  group  for  these  extensions. 

Recommendation:  NIST  must  take  advantage  of  the  present 

opportunity  to  inject  CALS  requirements  during  the  study  and 
definition  phase  for  the  new  ISO  CGM  extensions  work.  The  NIST 
representative  must  be  funded  to  participate  in  domestic  and 
international  CGM  meetings  on  CALS  behalf. 

Recommendation:  Due  to  the  longer  than  anticipated  timeframe  of 

the  desired  CGM  extensions,  NIST  suggests  that  the  scope  of  the 
NIST  representative's  task  in  FY  89  include  a  reassessment  of 
extending  the  CALS  AP  (MIL-D-CGM)  in  the  interim  by  inclusion  of 
registered  graphical  items  as  these  become  stable.  This 
recommendation  implies  that  planning  a  MILSPEC  for  CGEM  (that  is. 
Addenda  1,  2  and  3  of  CGM)  is  premature  at  the  present  time. 
Rather,  more  time  is  necessary  to  evaluate  how  long  the  standards 
process  is  likely  to  take  before  committing  to  a  MILSPEC  for 
CGEM.  The  plan  that  was  asked  for  now  should  be  a  product  of  the 
coming  fiscal  year,  since  it  depends  so  much  on  the  stability  and 
timeliness  of  these  Addenda  within  the  standards  process.  Either 
of  the  following  scenarios  is  a  possibility: 

(1)  Continue  adding  functionality  to  MIL-D-CGM  via  stable 
registration  proposals  and/or  Addendum  1.  (This  is 
what  the  above  recommendation  is  for  FY  89.) 

(2)  Use  CGEM  Addendum  1,  along  with  the  more  ‘stable 
registration  proposals,  as  the  basis  of  a  first  draft 
MILSPEC  CGEM,  and  then  build  in  the  other  Addenda  as 
they  become  standardized. 

(3)  Continue  as  in  step  l,  but  instead  of  having  2 
MILSPEC s,  have  one  in  future  (in  probably  2  to  3  years 
time)  which  includes  MIL-D-CGM  as  well  as  the 
standardized  versions  of  CGEM  Addenda,  thereby 
superseding  MIL-D-CGM  (if  allowable  in  DOD) . 
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GLOSSARY 


ASC  X3H3  Accredited  Standards  Committee  X3H3,  the  ANSI 
accredited  committee  responsible  for  computer  graphics 
standards  in  the  US. 

X3H3.3  The  subcommittee  of  X3H3  that  is  responsible  for  CGM 
and  CGI. 

ISO/IEC  JTC1/SC24  International  Standards  Organization,  Joint 
Technical  Committee  l.  Standing  Committee  24,  the 
international  counterpart  to  X3H3. 

ISO  TC97/SC21/WG2  The  predecessor  to  SC24  (prior  to  December 
1987) . 

WG3  The  working  group  of  SC24  responsible  for  standards 

work  in  metafiles  and  device-level  interfaces,  i.e., 
CGM  and  CGI. 

Metafile  Rapporteur  Group  (MRG)  The  sub-group  of  WG3  responsible 
for  CGM  maintenance  and  CGM  extensions. 

Working  Draft  (WD)  The  first  complete  draft  of  a  proposed  ISO 
standard,  the  starting  document  for  subsequent  work  and 
review* 

Proposal (DP)  The  second  stage  in  the  ISO  processing 
pipeline.  After  national  bodies  have  commented  on  the 
WD,  it  is  altered  and  refined  and  then  registered  as  a 
DP.  Another  round  of  ballot  and  comment  takes  place  on 
the  DP. 

Proposed  Draft  Addendum,  the  same  as  DP,  but  for  an 
addendum  as  opposed  to  a  standalone  project. 

International  Standard  (DIS)  The  project  stage  in  the  ISO 
pipeline  after  DP.  The  technical  content  of  the 
project  is  supposedly  highly  stable  and  it  is  expected 
that  IS  text  can  be  produced  subsequent  to  processing 
the  DIS  ballot  results. 

Draft  Addendum,  the  same  as  DIS,  but  for  an  addendum  as 
opposed  to  a  standalone  project. 

International  Standard  (IS)  The  final  stage  in  the  ISO  pipeline, 
nothing  remains  but  possibly  the  printing. 


Draft 

PDAD 

Draft 

DAD 


American  National  Standard  (ANS)  The  final  stage  in  the  ANSI 
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pipeline,  nothing  remains  but  possibly  the  printing. 


CGH 

CGI 


GKS 

GKSM 

CGEM 

BSI 

DIN 

AFNOR 


Computer  Graphics  Metafile,  ANSI  standard  X3. 122-1986 
and  ISO  standard  ISO  8632/1-4  1987. 

Computer  Graphics  Interface,  another  ANSI/ISO  standards 
project,  currently  at  the  2nd  DP  stage.  CGI  is  an 
interface  standard  which  exists  about  at  the  level  of 
the  CGM  in  the  graphics  pipeline  (device  level) .  CGI 
is  an  interactive  (input)  and  highly  extended  and 
enriched  interface  specification,  whereas  CGM  has 
output-only  functionality  (for  picture  definition)  and 
is  a  picture  description  protocol  (a  graphical 
database) .  CGI  embeds  CGM  output  functionality  as  a 
subset. 

Graphical  Kernel  System,  an  application  programmer 
interface  to  computer  graphics,  now  an  ANSI  and  ISO 
standard. 

Metafile  for  use  with  GKS.  One  was  proposed  in  non¬ 
standard  Annex  E  of  GKS.  Work  on  it  was  deferred  in 
favor  of  CGM,  and  now  of  extended  CGM  (CGEM) . 

Computer  Graphics  Extended  Metafile,  a  set  of  addenda 
and  extensions  to  CGM,  being  processed  by  ISO, 
currently  nearing  DP  stage. 

British  Standards  Institute,  the  British  equivalent  of 
ASC  X3H3. 

The  German  equivalent  of  ASC  X3H3. 

The  French  equivalent  of  ASC  X3H3 . 
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APPENDIX  1 

ADDENDUM  3  INPUT  FOR  BERLIN  SC24  MEETING 
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Purpose 


The  purpose  of  this  addendum  Is  to  extend  the  CGM  to  effectively  fulfill 
the  picture  transfer  requirements  of; 

1)  Engineering  drawing  and  technical  Illustration 

2)  Graphics  arts  quality  pictures.  Including  geometric  graphics,  raster 
Images,  and  text 

3)  Technical  publishing 

An  additional  Intent  Is  to  keep  pace  with  the  graphics  requirements  of 
office  systems,  especially  ODA  requirements. 


Scope 

This  addendum  comprises  a  set  of  elements  which  will  extend  the 
capabilities  of  CGM  as  needed  to  meet  additional  user  requirements  In 
engineering  drawing,  graphics  arts,  and  technical  publishing.  The  set  of 
elements  should  include  nil  elements  necessary  to  meet  tho.se  requirements. 
It  should  be  the  minimal  set  sufficient  to  meet  those  requirements 
effect Ively. 

The  following  preliminary  list  of  capabilities  Is  identified  as  necessary 
to  meet  these  requirements. 

1)  Advanced  2D  graphics,  to  Include; 

-  Bezier  curves 

-  Rational  B-spllnes 

-  Parametric  spline  curves 

-  Line  attributes  of  cap,  miter,  and  join 

-  Composite  line  primitive 

-  User-defined  line  types 

-  User-defined  hatch  styles 

-  Arbitrary  text  path 

-  Conics,  and  conic  arcs 

2)  Text  and  font  model  of  ISO  95^1.  Information  Process lng--Font  and 
Character  Information  Interchange. 

3)  Picture  composition  and  control,  to  include; 

-  Arbitrary  clipping  boundary  (general  closed  curve) 

-  Shielding 

-  Alignment 

)  Additional  color  models  beyond  RGB 

-  CIE- 

-  CMYB 

-  Named  colors 

5)  Additional  raster  graphics  (scanned  image)  capalUl  it  ie? 

6)  Symbols;  external  reference  to  "standard"  libraries  of  named  symbols 

The  scope  of  this  addendum  assumes  that  the  capabilities  of  CGM  Addendur.i  I 
and  Addendum  2  are  available. 

The  remainder  of  this  document  constitutc.s  the  preliminary  work  which  has 
been  performed  to  date. 
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END  COMPOUND  TEXT  PATH  delimits  the  end  of  a  compound  text  path 
def inlt ion. 

References : 


5.X.X  BEGIN  CLIP  REGION 
Parameters : 


none 


Description: 

BEGIN  CLIP  REGION  delimits  the  beginning  of  a  definition  of  a  entity 
that  wii.1  provide  the  clipping  region.  When  CLIP  INDICATOR  is  on' 
only  the  portions  of  graphics  elements  inside  or  on  the  boundary  of  the 
clipping  region  are  drawn.  The  elements  that  make  up  the  clipping 
region  can  be  any  combination  of  closed  or  non-closed  elements  such  as 
POLYLINE,  DISJOINT  POLYLINE,  POLYGON,  POLYGON  SET,  CIRCULAR  ARC  3 
POINT,  CIRCULAR  ARC  3  POINT  CLOSE,  CIRCULAR  ARC  CENTRE,  CIRCULAR  ARC 
CENTRE  CLOSE,  ELLIPTICAL  ARC  CLOSE,  or  <new  curve  elements>.  The 
entity  thus  defined  is  essentially  a  closed  figure  whose  boundary  is 
used  as  the  clipping  boundary. 


Once  defined,  the  clipping  region  takes  the  place  of  the  clipping 
region  defined  in  CLIP  RECTANGLE. 


References : 


5.X.X  END  CLIP  REGION 
Parameters: 
none 

Description: 

END  CLIP  REGION  delimits  the  end  of  a  clipping  region  definition. 

References : 


5.X.X  BEGIN  SHIELD  REGION 
Parameters : 
none 

Description: 

BEGIN  SHIELD  REGION  delimits  the  beginning  of  a  definition  of  a  entity 
that  will  provide  the  shielding  region.  When  SHIELD  INDICATOR  is  on' 
only  the  portions  of  graphics  elements  outside  of  the  shielding  region 
are  drawn.  The  elements  that  make  up  the  shielding  region  can  be  any 
combination  of  closed  or  non-closed  elements  such  as  POLYLINE,  DISJOINT 
POLYLINE,  POLYGON,  POLYGON  SET,  CIRCULAR  ARC  3  POINT,  CIRCULAR  ARC  3 
POINT  CLOSE,  CIRCULAR  ARC  CENTRE,  CIRCULAR  ARC  CENTRE  CLOSE,  ELLIPTICAL 
ARC  CLOSE,  or  <new  curve  elements>.  The  entity  thus  defined  is 
essentially  a  closed  figure  whose  boundary  is  used  as  the  shielding 
boundary. 


References : 
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5-X  Control  Elements 


5.X.X  BECIN  COMPOUND  LINE 
Parameters : 

none 

Description: 

BEGIN  COMPOUND  LINE  delimits  the  beginning  of  a  definition  of  a  entity 
that  will  have  consistent  line  attributes  and  will  be  treated  as  a 
single  "compound  primitive”.  The  elements  that  make  up  the  compound 
line  can  be  any  combination  of  non-closed  line  elements  such  as 
POLYLINE,  DISJOINT  POLYLINE,  CIRCULAR  ARC  3  POINT,  CIRCULAR  ARC  CENTRE, 
ELLIPTICAL  ARC,  or  <new  curve  elements>. 

References: 


5.X.X  END  COMPOUND  LINE 
Parameters: 
none 

Description: 

END  COMPOUND  LINE  delimits  the  end  of  a  compound  line  definition. 
References: 


5.X.X  BEGIN  COMPOUND  TEXT  PATH 
Parameters : 

none 

Description: 

BEGIN  COMPOUND  TEXT  PATH  delimits  the  beginning  of  a  definition  of  a 
entity  that  will  provide  the  path  in  which  a  text  string  will  be  drawn. 
The  elements  that  make  up  the  compound  text  path  can  be  any  combination 
of  non-closed  line  elements  such  as  POLYLINE,  DISJOINT  POLYLINE, 
CIRCULAR  ARC  3  POINT,  CIRCULAR  ARC_ CENTRE,  ELLIPTICAL  ARC,  or  <new 
curve  elements). 

Once  defined,  the  compound  text  path  takes  the  place  of  the  text  path 
as  defined  by  the  TEXT  PATH  element  and  the  CHARACTER  ORIENTATION 
elements.  The  skew  of  the  characters  is  still  relative  to  that 
specified  in  the  CHARACTER  ORIENTATION  element,  but  the  placement  of 
subsequent  characters  is  along  the  compound  text  path  instead  of  in  a 
line  along  the  character  up  vector  or  character  base  vector. 

References : 


5.X.X  END  COMPOUND  TEXT  PATH 
Parameters: 
none 

Description: 
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5.X.X  END  SHIELD  REGION 


Parameters : 
none 

Description: 

END  SHIELD  REGION  delimits  the  end  of  a  shielding  region  definition. 

References: 

5-X.X  SHIELDING  INDICATOR 
Parameters : 

shield  Indicator  (one  of:  off,  on)  (E) 

Description: 

When  SHIELD  INDICATOR  Is  'off,  shielding  of  graphical  primitive 
elements  Is  not  required. 

When  SHIELD  INDICATOR  Is  on’,  only  those  portions  of  graphical 
primitive  elements  outside  of  the  shielding  region  are  drawn. 

References : 
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All  of  the  fontmetrlc  elements  ( FONTMETRIC  DEFINITION  LIST,  CHARACTER  KERNING 
MODE,  CHARACTER  KERNING  TABLE.  FCS  TYPE,  FC3  INTEGER  PRECISION,  FCS  REAL 
PRECISION,  and  FCS  EXTENT)  are  Metafile  Descriptor  Elements. 


5.X.X  FONTMETRIC  DEFINITION  LIST 

Parameters: 

list  o\  : 

font  index  (IX) 
character  index  (C) 

left  bearing  (format  to  be  determined) 
right  bearing  (format  to  be  determined) 
character  height  (format  to  be  determined) 
offset  from  baseline  (format  to  be  determined) 

Description: 

The  fontmetrlc  Information  for  each  character  used  in  each  font 
specified  is  defined  by  this  element.  If  this  element  is  used,  then 
the  fontmetrlc  data  for  each  character  used  in  the  metafile  must  be 
specified.  Characters  not  used  by  the  metafile  may  also  be  specified, 
but  are  not  required. 

References : 


5-X.X  CHARACTER  KERNING  MODE 
Parameters: 

character  kerning  mode  (one  of:  none,  pair,  sectored)  (E) 

Description: 

Defines  the  kerning  style,  if  any,  for  the  metafile. 
References: 


5.X.X  CHARACTER  KERNING  TABLE 
Parameters: 

To  be  determined. 

Description: 

The  data  defined  by  this  element  will  be  dependant  upon  which,  if  any, 
kerning  styles  are  supported.  In  general,  however,  the  information 
will  be  that  which  is  required  to  kern  characters.  The  most  prevalent 
form  of  kerning  is  character  pair  kerning. 

References: 


5.X.X  FCS  TYPE 
Parameters: 

Font  coordinate  type  (one  of:  Integer,  real,  VDC)  (E) 

Description: 

The  single  parameter  is  an  enumerated  value  that  declares  the  data 
type.  Integer  or  real,  of  the  font  coordinate  space.  Font  coordinate 
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space  may  be  different  than  VDC  space  because  higher  precision  may  be 
necessary  to  accurately  define  the  fontmetrlc  data.  However,  In  the 
font  coordinate  type  Is  VDC,  then  the  font  coordinate  space  will  map  to 
VDC  space.  In  this  case,  no  additional  specification  for  font 
coordinates  (PCS  INTEGER  PRECISION,  PCS  REAL  PRECISION,  or  PCS  EXTENT) 
need  be  specified. 

References: 


5.X-X  PCS  INTEGER  PRECISION 
Parameters: 

Encoding  dependant. 

Description: 

The  indicated  Integer  precision  for  fontmetrlc  data.  The  precision  is 
defined  as  the  field  width  measured  In  units  applicable  to  the  specific 
encoding. 

References: 


5.Z.X  PCS  REAL  PRECISION 
Parameters : 

Encoding  dependant. 

Description: 

The  Indicated  real  precision  for  fontmetrlc  data.  The  precision  Is 
defined  as  the  field  width  measured  in  units  applicable  to  the  specific 
encoding. 

References : 


5.X.X  PCS  EXTENT 

Parameters : 

first  corner  (P) 
second  corner  (P) 

Description: 

The  two  corners  define  a  rectangular  extent  in  font  coordinate  space 
that  demarcates  a  "font  window".  Each  character  within  a  font  must  be 
contained  completely  within  this  window. 

References : 
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5.x  Attribute  Elements 


5.X.X  Line  Type  Definition 
Parameters : 

linetype  (IX) 

dash  unit  selector  (one  of:  VDC,  mm,  native  device  units,  abstract)  (E) 

dash  repeat  length  (R) 

adaptive  flag  (one  of:  no,  yes)  (E) 

list  of  dash  elements  (nl) 

Description: 

This  element  defines  a  linetype  and  associates  it  with  an  index  for 
future  reference.  Parameter  'linetype'  is  the  index  of  linetype  being 
defined.  The  parameter  list  of  dash  elements'  is  the  definition  to  be 
associated  with  the  index.  The  first  element  is  a  dash,  second  a  space, 
etc.  —  the  defined  linetype  is  solid  for  II  units,  gap  for  12  units, 
solid  for  13  units,  etc.  N  must  be  positive,  and  each  dash  element  (I) 
non-negative.  N«1  means  a  solid  line;  I«0  interpreted  as  a  dot. 

The  units  of  the  dash  repeat  length'  are  specified  by  the  dash  unit 
selector'  parameter.  The  value  of  abstract'  indicates  that  the 
implementation  may  normalize  and  map  the  sum  of  the  dash  pattern  elements 
at  its  discretion.  The  dash  repeat  length'  defines  the  length  of  one 
complete  cycle  of  the  dash  pattern,  measured  in  the  units  of  dash  unit 
selector ' . 

An  "adaptive"  linetype  is  one  where  every  vertex  falls  on  an  inked 
portion  of  the  line.  This  is  accomplished  in  plotters  by  temporarily 
modifying  the  duty  cycle  for  each  line  segment  (celling  function)  such 
that  there  is  always  an  Integral  number  of  repeats  (and  all  predefined 
llnetypes  have  their  gaps_array  defined  such  that  they  begin  and  end  with 
inked  or  "pen  down"  portions). 

References : 


5.X.X  Hatch  Style  Definition 
Parameters : 

hatch  index  ( IX ) 

style  indicator  (one  of:  parallel,  crosshatch)  (E) 

hatch  space  units  selector  (one  of:  VDC,  mm,  device  units,  abstract)  (E) 
angle  (2R) 

duty  cycle  length  (R) 

list  of  hatch  elements  (nl)  -  I>»0,  n>»2 
Description: 

This  element  defines  a  hatch  style  and  associates  it  with  an  index 
for  future  reference. 

The  "hatch  index'  parameter  defines  the  index  of  hatch  style  being 
defined.  The  'list  of  hatch  elements'  is  an  array  that  defines 
alternating  line  width  and  gap  width  —  i.  e.  ,  the  width  of  a  hatch  line 
followed  by  the  width  of  the  space  to  the  next  hatch  line.  The  center  of 
the  first  hatch  line  is  matched  up  with  PATTERN  REFERENCE  POINT,  if 
Implemented.  0  Interpreted  as  thinnest  line  width  available. 
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The  'hatch  space  units  selector'  speclCLes  the  units  of  'duty  cycle 
length'.  It  also  controls  the  manner  of  trarisformat  ion  of  the  hatching; 
If  VDC ,  then  the  hatching  transforms  with  segment  transform  and 
anisotropic  transforms  (as  if  hatching  had  done  POLYLINES):  otherwise, 
the  hatching  is  like  "wallpaper"  th.at  shows  through  the  polygon-shaped 
hole  —  everything  is  defined  in  device  units  and  are  doing  hatching  in 
device  space.  The  value  of  abstract'  indicates  that  the  implementation 
may  normalize  and  map  the  sum  of  the  dash  pattern  elements  at  its 
discretion.  The  duty  cycle  length'  Is  measured  perpendicular  to  the 
hatch  line.  The  sum  of  hatch  elements  in  the  hatch  element  list  is 
normalized  to  this  distance  before  presentation  of  the  hatch  on  the  view 
surface. 

The  'angle'  parameter  is  measured  in  the  units  specified  by  the  hatch 
space  units  selector'.  It  consists  of  two  components,  dx  and  dy , 
defining  a  vector. 


5.X.X  Line  Cap 
Parameters : 

line  cap  indicator  (one  of;  butt,  round,  projecting  square)  (E) 

Description: 

The  line  cap  style  l.s  defined  for  subsequent  line  elements.  The  line  cap 
style  determines  the  appearance  of  open  endpoints  (as  opposed  to  Interior 
vertices)  of  line  elements.  The  defined  styles  arc: 

butt  cap;  the  line  is  squared  off  at  the  endpoint,  there  is  no 
projection  beyond  the  endpoint. 

* 

round  cap:  a  semicircular  arc  with  diameter  equal  to  the  line  width 
is  drawn  around  the  endpoint  and  filled  in.  The  drawn  line  thus 
projects  beyond  the  endpoint. 

projecting  square  cap:  the  line  is  .squared  off  at  a  distance  equal  to 
half  the  line  width  beyond  the  endpoint. 

References : 


5'X>X  Line  Join 
Parameters : 

line  join  indicator  (one  of:  miter,  round,  bevel)  (E) 

Description: 

The  line  join  style  is  defined  for  subsequent  line  elements.  The  line 
join  style  defines  the  appearance  of  interior  vertices  of  polyline 
elements  and  of  compound  line  elements.  The  defined  styles  are: 

miter  join;  the  outer  edges  of  the  two  adjoining  line  segments  are 
extended  until  they  meet  at  a  point. 

round  join:  a  circular  arc  with  diameter  equal  to  the  line  width  Is 
drawn  around  the  vertex  between  the  adjoining  segments  and  is  filled 
'n,  prr  iuclng  a  rounded  corner. 

bevel  join:  the  adjoining  line  segments  are  terminated  with  a  butt 
cap,  and  the  resulting  triangular  notch  Is  filled  in. 

29 


References : 


5-X.X  Edge  Cap 
Parameters : 

edge  cap  Indicator  (one  of:  butt,  round,  projecting  square)  (E) 
Description: 

The  edge  cap  style  Is  defined  for  subsequent  edge  elements.  The  edge  cap 
style  determines  the  appearance  of  open  endpoints  of  filled  area  edges 
(such  as  may  result  from  a  mixture  of  visible  and  Invisible  edge 
segments).  The  defined  styles  are: 

butt  cap:  the  edge  Is  squared  off  at  the  vertex,  there  Is  no 
projection  beyond  the  endpoint. 

round  cap:  a  semicircular  arc  with  diameter  equal  to  the  edge  width 
Is  drawn  around  the  endpoint  and  filled  In.  The  drawn  edge  thus 
projects  beyond  the  endpoint. 

projecting  square  cap:  the  edge  Is  squared  off  at  a  distance  equal  to 
half  the  edge  width  beyond  the  endpoint. 

References : 


5<X-X  Edge  Join 
Parameters: 

edge  join  Indicator  (one  of:  miter,  round,  bevel)  (E) 

Description: 

The  edge  join  style  Is  defined  for  subsequent  filled  elements.  The  edge 
join  style  defines  the  appearance  of  Interior  vertices  of  filled  area 
elements.  The  defined  styles  are: 

miter  join:  the  outer  edges  of  the  two  adjoining  edge  segments  are 
extended  until  they  meet  at  a  point. 

round  join:  a  circular  arc  with  diameter  equal  to  the  edge  width  Is 
drawn  around  the  vertex  between  the  adjoining  segments  and  is  filled 
In,  producing  a  rounded  corner. 

bevel  join:  the  adjoining  edge  segments  are  terminated  with  a  butt 
cap,  and  the  resulting  triangular  notch  is  filled  in. 

References : 


5>X>X  Miter  Limit 
Parameters : 

miter  limit  (R) 

Description: 

Mitered  corners  can  extend  very  far  beyond  the  line  vertex  if  the  angle 
between  the  adjoining  line  segments  Is  small.  Miter  length  Is  defined  to 
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be  the  distance  from  the  point  at  which  the  inner  edges  of  the  adjoining 
line  segments  meet  to  the  point  at  which  the  outer  edges  meet.  If  miter 
length  exceeds  the  miter  limit  parameter,  then  the  joining  line 
segments  are  rendered  with  a  bevei  join  instead  of  a  miter  join. 

Miter  limit  is  measured  as  a  scale  factor  applied  to  the  current  line 
width.  Miter  limit  applies  to  line  elements  and  edges  of  filled  areas. 

References: 


5.x 'X  External  Symbol 
Parameters : 

To  be  determined. 

Description: 

Reference  to  external  defined  symbol  libraries  is  provided.  The 
mechanism  of  this  element  is  yet  to  be  defined. 
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The  following  "Abstract  Specification  of  Eiements"  Is  of  the  form  in  ANSI 
X3. 122  -  Part  1,  Section  5.  Most  of  what  follows  Is  based  on  the  entities 
found  In  ICES: 

S-6.X  CONIC  ARC 

Parameters: 

start  point  (P) 
end  point  (p) 

A,B,C,D,E,F  (6R) 

Description: 

A  conic  arc  is  drawn  which  is  defined  as  follows: 

A  conic  arc  is  defined  by  the  end  points  and  the  six  parameters.  The 
conic  arc  itself  is  defined  by  the  six  parameters  in  the  following 
equation: 

A*(XT**2)  ♦  B*XTy.YT  ♦  C*(YT**2)  ♦  D*XT  ♦  E*YT  ♦  F  >  0 

where  XT,  YT  is  the  plane  of  the  definition  space.  In  order  for  the 
conic  arc  to  be  processed  correctly  by  the  receiving  system  given  the 
above  representation,  the  conic  arc  entity  must  be  positioned  such  that 
each  of  its  axes  is  parallel  to  either  the  XT  axis  or  YT  axis.  The  arc 
is  then  positioned  correctly  In  VDC  space  by  using  the  value  of  the 
CONIC  ARC  TRANSFORMATION  MATRIX  element. 

To  determine  the  form  of  the  conic  arc.  the  quantities  Q1 ,  Q2  and  Q3  are 
defined  as  follows: 
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In  tlie  case  where  the  conic  arc  is  elliptical,  to  distinguish  the  arc  in 
question  from  its  compliment,  the  direction  of  the  arc  with  respect  to 
the  definition  space  must  be  from  start  point  to  end  point  in  a 
counterclockwise  direction. 


In  the  case  where  the  conic  arc  is  parabolic  or  hyperbolic,  the 
parameterization  defines  a  unique  portion  of  the  parabola  or  a  unique 
portion  of  a  branch  of  the  hyperbola,  thus  tlie  direction  is  irrelevant. 

The  direction  of  the  conic  arc  with  respect  to  VDC  space  is  determined 
by  the  original  direction  of  the  arc  in  definition  space,  in  conjunction 
with  the  action  of  the  CONIC  ARC  TRANSFORMATION  MATRIX  element. 

References: 
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5.6.x  CONIC  ARC  TRANSFORMATION  MATRIX 


Parameters : 


matrix  elements 

If  the  VDC  type 
R11,R12,R21,R22 

If  the  VDC  type 
R11,R12,R21,R22 

coordinate  offset 


is  ' Integer 
(^I) 

Is  ■ real '  , 
(^R) 

(P) 


Description: 

This  element  Is  intended  to  work  in  conjunction  with  the  CONIC  ARC 
element  to  transform  the  conic  arc  from  definition  space  to  VDC  space. 
The  Transformation  Matrix  entity  transforms  the  definition  space  point 
coordinates  by  means  of  a  matrix  multiplication  and  then  the  addition  of 
an  offset. 


The  notation  for  this  transformation  is  as  follows: 

I  Rll  R12  1  1  Xln  !  ♦  I  Tl  I  -  :  Xout  I 
I  R21  R22  1  1  Yin  !  !  T2  !  1  Yout  I 

where  iRlj!  is  the  transformation  matrix,  (Xin,Yin)  is  the  coordinate  to 
be  transformed,  (T1,T2)  is  the  offset,  and  (Xout, Yout)  is  the  coordinate 
resulting  from  the  transformation.  Both  the  input  and  output  coordinate 
systems  are  assumed  to  be  orthogonal,  cartesian  and  right-handed. 

References: 


5.6.x  PARAMETRIC  SPLINE  CURVE 

Parameters : 

curve_type  (IX) 

H-degree  of  continuity  (I) 

N-number  of  segments  (I) 

T-break  point  list  for  polynomial  ((N-.1)R) 

X  coordinate  polynomial  list  (N  sets  of  four) 

AX, BX,CX,DX  ((4*N)R) 

Y  coordinate  polynomial  list  (M  sets  of  four) 

AY, BY,CY,DY  ((A*N)R) 

Description: 

The  parametric  curve  to  be  drawn  is  defined  as  follows: 

The  parametric  spline  curve  is  a  sequence  of  parametric  polynomial 
segments.  The  parameterization  shown  above  is  generalized  to  allow  for 
the  representation  of  many  different  parametric  spline  curves  using  this 
one  element.  The  curve_type  parameter  indicates  the  type  of  parametric 
curve  as  It  was  represented  in  the  sending  system  before  being  converted 
to  this  generic  form.  The  following  curve  types  have  been  assigned: 


1:  linear 
2:  quadratic 
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3:  cubic 

A:  Wllson-Fowler 
5:  modified  Wilson-Fowler 
6;  B  spline 

Values  above  6  are  reserved  for  registration  and  future  sf andard izat ion . 
and  negative  values  are  available  for  implementation-dependent  use. 

The  degree  of  continuity  parameter,  H,  indicates  the  smoothness,  or 
continuity  of  the  curve  with  respect  to  arc  length.  If  H«0,  the  curve 
is  continuous  at  all  break  points.  If  H«i ,  the  curve  is  continuous  and 
has  slope  continuity  at  all  break  points.  If  H*2 ,  the  curve  is 
continuous  and  has  both  slope  and  curvature  continuity  at  all  break 
points. 

The  number  of  segments  parameter,  N,  is  the  number  of  polynomial 
segments  to  be  used  to  define  the  curve.  Each  X,Y  polynomial  segment  is 
evaluated  using  the  eight  polynomial  coefficients  associated  with  that 
segment  ( AX , BX ,CX , DX , AY , BY ,CY , DY).  Each  segment  is  delimited  by  its 
respective  breakpoint,  T. 

The  following  cubic  polynomial  equations  will  return  the  coordinates  of 
the  points  of  the  i-th  segment  of  the  curve.  Note  that  the  coefficients 
D,  or  C  and  D  will  be  zero  if  the  polynomials  are  of  degrees  2  or  1 , 
respect ively : 

X(u)  -  AX(i)  ♦  BX(l)(s)  ♦  CX(i)(s«*2)  *  nX(  l)(si»vr3) 

Y(u)  -  AY(1)  ♦  BY(l)(s)  >  CY(i)(s**2)  ♦  DY(l)(s,.-*3) 

where  T(l)  <■  u  <*  T( 1*1 ) , i»l ,. .  .  ,N  and  s  »  u  -  T(l). 

The  terminate  point  and  derivatives  are  derived  without  computing  the 
polynomials  by  evaluating  the  Nth  polynomials  and  derivatives  at 
u  ■  T(N  *  1).  These  data,  divided  by  the  appropriate  factorial  ( 1. e. 
the  second  derivative  divided  by  2!,  the  third  by  3!),  are  used  as  the 
N*1  or  terminate  point  values. 

References : 


5.6.x  RATIONAL  B-SPLINE  CURVE 
Parameters: 

K-upper  index  of  sum  (I) 

M-degree  of  the  basis  function  (I) 
curve_open  flag  (one  of:  open,  closed)  (E) 
equat lon_type  flag  (one  of;  rational,  polynomial)  (E) 
periodic  flag  (one  of:  non-periodic,  periodic)  (E) 

T-knot  sequence  list  ((K*M*1)R) 

W-welgh(;  list  ((K*1)R) 
control  point  list  ((K*1)P) 
start_param, end_param  (2R) 

Descript  ion: 

A  rational  spline  curve  is  drawn  which  is  defined  as  follows; 

The  parametric  equation  governing  the  definition  of  the  rational 
B-spllne  curve  is  shown  in  the  following  expression: 
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W(0)*P(0)*b0(t)  W(l)*P(l)*bl(t) 


w(K)*P(K)*bK( t ) 


W(0)v,b0(t)  W(l)*bl(t)  W(K)vbK(t) 

where  W( i )  are  the  weights,  P( 1 )  are  the  control  points  and  bi  are  the 
basis  functions. 

The  bi  basis  functions  are  all  non-negative  piecewise  polynomials 
determined  by  the  degree  M,  and  the  knot  sequence  T.  T  is  a 
non-decreasing  list  of  real  numbers  T( -M) , . . . T( 0) , . . . T( K»1 ) .  Each 
function  bi  is  supported  by  the  knot  sequence  interval  [T( i-M) ,T( !♦! )  1. 
Between  any  two  adjacent  knot  values,  the  corresponding  basis  function 
can  be  expressed  as  a  single  polynomial  of  degree  M. 

The  curve  Itself  is  parameterized  where: 

start_param  <=  t  <»  end_param, 

T(0)  <»  start_parara  <  end_param  <-  T(N) 

Thus  for  any  parameter  value  t  between  T(0)  and  T(K*1),  the  sum  of  the 
basis  functions  satisfies  the  following  Identity: 

b0(t)  -  bl(L)  *  _  ♦  bK(t)  ,  1. 

If  the  beginning  and  ending  point*-  of  the  curve  are  identical,  then  the 
curve_open  flag  is  set  to  cloaed,  otherwise  it  is  set  to  open. 

If  all  of  the  weights  in  the  -weij-ht  list  W  are  not  equal,  then  the 
equat lon_type  flag  is  set  to  rational.  Otnerwise.  if  all  of  the  weights 
are  equal,  then  all  of  the  weights  cancel,  the  denominators  sum  to  one 
and  the  equat ion_type  becomes  polynomial. 

References : 


5.6.x  COMPRESSED  PEL  ARRAY 
Parameters : 

T-encodlng  type  (one  of:T4,T6)  (E) 

P-pel  path  (one  of : 0 . 90 , 180 , 270)  (E) 

I.-llne  progression  (one  oC: '^0,270)  (E) 

S-pel  spacing  (R) 
spac ing_rat lo  (R) 

N-number  of  pels  per  line  (I) 

NL-number  of  lines  (I) 
pel  array  (BS) 

Description: 

A  compressed  pel  array  image  is  defined  as  follows: 

The  encoding  type  parameter,  T.  specifies  the  CCITT  compression  format 
used  to  encode  the  image.  If  T  is  specified  as  "T^”  ,  the  image  is 
encoded  according  the  one  or  two  dimensional  scheme  defined  in  CCITT 
Recommendation  T.  ^  (Group  3  facsimile).  If  T  Is  'Tb  "  .  the  image  is 
encoded  according  to  the  two  dimensional  scheme  defined  in  CCITT 
Recommendation  T.  6  (Group  i*  facsimile). 

The  pel  path  parameter,  P,  is  the  direction  of  progression  of  successive 
pels  along  a  line  relative  to  the  VDC  X  axis.  This  parameter.  In 
conjunction  with  the  pel  spacing,  S,  and  the  number  of  pels  per  line,  N, 
implicitly  define  the  line  position,  length  and  granularity  for  each 
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line  in  the  dGcoded  pel  array.  S  Is  defined  as  the  ratio  m/n,  where  "id" 
is  the  iltie  length  in  SMUs  (1200  SMUs  per  inch)  occupied  by  "n"  pel 
spaces. 

The  line  progression  parameter.  L,  is  the  direction  of  progression  of 
successive  of  pel  lines  and  is  expressed  as  a  direction  relative  to  P. 

L,  in  conjunction  with  the  spac 1 ng_ra t io  and  the  number  of  lines.  NL , 
implicitly  defines  the  size  of  the  decoded  image  in  the  direction  of  L. 
The  line  spacing  (LS)  of  the  lines  of  pels  can  be  determined  as  follows: 

LS  »  spaclng_rat io  *  S 

or  rather,  the  spacing_ratlo  is  the  ratio  of  line  spacing  to  pel 
spac ing. 

The  pel  array  Itself  is  stored  in  either  of  the  formats  defined  by  T, 
encoded  as  a  bit_stream. 

References : 


5.6.x  PEL  ARRAY  CLIP  RECTANGLE 

Parameters: 

X1,Y1,X2.Y2  (41) 

first  corner  (P) 
second  corner  (P) 

Description: 

The  element  defines  the  rectangular  area  of  pels  in  the  decoded  pel 
array  that  is  to  appear  in  the  picture. 

The  four  Integers  form  two  coordinate  pairs.  (XI. Yl)  and  (X2.Y2) 
corresponding  to  the  first  and  last  pels  to  appear,  respectively.  For 
example.  (6,2)  would  specify  the  seventh  pel  in  line  3.  given  that  (0.0) 
specifies  the  first  pel  on  the  first  line.  The  default  for  the  first 
coordinate  is  (0.0).  and  the  default  for  the  second  is  (N-].L-1).  where 
N  is  the  number  of  pels  per  line  and  L  is  the  number  of  lines  from  the 
COMPRESSED  PEL  ARRAY  element. 

The  two  corner  points  define  the  pel  array  clip  rectangle  in  VDC  space. 
Tile  first  pel  defined  above  will  appear  at  tlie  first  corner,  and  only 
those  portions  of  the  decoded  pel  array  from  the  COMPRESSED  PEL  ARRAY 
element  inside  or  on  the  boundary  of  the  pel  array  dip  rectangle  will 
be  drawn. 
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In  addition  to  the  proposed  element  listed  and  described  on  the  preceedlng 
pages,  elements  to  add  support  for  additional  color  inodles  (such  as  CIE, 
CMYB,  HIS,  etc.  )  Is  also  under  consideration.  The  form  and  content  of  these 
new  (color  modle  related)  elements  Is  yet  to  be  determined. 


I 
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APPENDIX  2 

AODENDCM  1  PDAD  TEXT 
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Paga  1 


Sub-dauM  0.1 ;  Add  ttw  fotlowHng  at  tha  and  at  tha  sub^lausa: 

This  pictura  dascription  indudas  static  imagas  and  graphical  sassion  captura  raquiramants. 

Pagal 

Sub-dausa  0.3:  Add  tha  foilawing  at  tha  and  of  itani  c): 

It  should  also  not  praduda  furthar  axtansions  to  support  futura  standards. 

Paga  1 

Sub-dausa  0.3:  Add  tha  foflo«ving  at  tha  and  of  itam  d): 

It  should  induda  tha  capability  to  support  both  GKS  picture  and  graphical  sassion  raquiramants. 

Paga3 

Sub-dausa  0.8:  Add  tha  followirtg  at  tha  and  of  tha  first  paragraph: 

Tha  CGM  as  axtandad  by  this  addendum  also  spadfias  tha  aiamants  raquirad  to  support  GKS  pictura  and 
graphical  session  captura. 

Paga4 

Clausa  1 :  Add  tha  folowing  at  tha  and  of  the  first  paragraph: 

This  pictura  dascription  IrKkidas  static  hnaga  and  graphical  sassion  captura  raquiramants. 

Paga4 

Clausa  1 :  Add  tha  taikiwing  at  tha  and  of  tha  second  paragraph: 

Tha  CGM  as  axtandad  by  this  addendum  also  contains  aiamants  that  dalmit  and  manipulate  groups  of 
aiamants  within  pictures.  Capability  is  provided  for  dynamic  picture  raganaration  such  as  is  raquirad  for 
graphical  sassion  captura. 

Paga9 

Sub-dausa  4.1 :  Add  tha  fdlawmg  at  tha  and  of  tha  list  of  dassas  of  aiamants: 

Segment  Elamants.  which  enable  tha  manipulation  and  appaararKs  of  aiamants  within  pictures. 
Segments  can  also  appear  outside  pictures  as  global  segments. 

Paga  9 

Sub-dausa  4.1 :  Add  tha  foilowirig  after  tha  third  paragraph: 

Graphical  output  primitivas  and  attributes  may  be  grouped  in  segments.  Segment  attribute  aiamants  control 
tha  appaararKa  of  segments.  Segments  can  appear  both  insida  arxf  outsida  pictures. 

Paga  10 

Sub-dausa  42:  Add  tha  fdlowing  at  tha  end  of  the  sub-dausa: 

Groups  of  elamants  within  piduras,  callad  segments,  are  delimited  by  BEGIN  SEGMENT  and  END 
SEGMENT.  Each  segment  is  uniquely  Idantifiad  by  a  segment  identifier. 
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Pagmil 


Add  th«  foilowring  sub-clauMS  after  sub-dausa  4.3.22: 

4.3.2.3  QKSMO  Set 

The  GKSMO  set  IrKfudes  ail  elemerrts  conforming  to  GKS  level  Oa  in  IS  7942. 


The  eiemenia  included  In  the  GKSMO  set  are: 

BEGIN  METARLE 
BIOMETARLE 
BEGIN  PICTURE 
BEGIN  PICTURE  BCXJY 
eiD  PICTURE 
METARLE  VERSION 
METARLE  DESCRIPTION 
VDCTYPE 

INTEGER  PRECISION 
REAL  PRECISION 
INDEX  PRECISION 
COLOUR  PRECISION 
COLOUR  INDEX  PRECISION 
MAXIMUM  COLOUR  INDEX 
METARLE  ELB^eiT  LIST 
METARLE  DEFAULTS  REPLACB4B«T 
FONT  LIST 

CHARACTER  SET  UST 
CHARACTER  COOING  ANNOUNCER 
vocEXTerr 
BACKGROUND  COLOUR 
MAXMUM  VDC  EXreTT 
VDC  INTEGBt  PRECISION 
VDC  REAL  PRECISION  . 

CUP  RECTANGLE 
MAKE  PICTURE  CURRENT 
PREPARE  VIEW  SURFACE 
UPDATE 

DEVICE  VIEWPORT 

DEVICE  VIEWPORT  SPECIFICATION  MODE 

DEVICE  VIEWPORT  MAPPING 

MODIFY  FONT  UST 

MODIFY  CHARACTER  SET  LIST 

POLYLINE 

POLYMARKER 

TEXT 

POLYGON 

CELL  ARRAY 

GOP 

LINE  BUNDLE  INDEX 

UNETYPE 

LINE  WIDTH 

UNE  COLOUR 

MARKER  BUNDLE  INDEX 

MARKER TYPE 

MARKER  SIZE 

MARKER  COLOUR 

TEXT  BUNDLE  INDEX 

TEXT  FONT 

TEXT  PRECISION 

CHARACTER  EXPANSION  FACTOR 

CHARACTER  SPACING 

TEXT COLOUR 

TEXT  PATH 
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TEXTAUGNMEt^ 

RLL  BUNDLE  INDEX 
B^TERlOn  STYLE 
FLL  COLOUR 
HATCH  INDEX 
PATTBU^MDEX 
FHJ.  REFERENCE  POINT 
PATTERN  TABLE 
PATTERN  SEE 
COLOUR  TABLE 
ASPECT  SOURCE  FLAGS 

CQPAPC 

APPLICATION  DATA 


Pagtil 

Sub-dauM  4.3:  AcM  tha  following  sub-clausa  aftar  sub-clausa  4.3.3: 

4.3.4  Mataflla  Catagorlaa 

4.3.4.1  Intreduetion 

Each  mataflla  fala  Into  a  paiteular  mataflla  eatagory.  Tha  matafHa  ealagory  may  ba  announcad  at  tha  start 
of  tha  mataAa.  This  Infonnalion  may  ba  usad  by  tha  intarpratar  to  daddo  If  tha  mataflla  can  ba  Intarpratad. 
Tha  dafault  mataflla  ealagory  is  of  tha  typa  *ogm‘  as  dafinad  by  IS  8632.  Tha  eatagory  ImpBas  that  tha 
matafHa  conforms  to  the  samanties  and  formal  grammar  of  that  category.  Tha  mataflla  catagorfas  may 
oaarlap.  Tha  ealagory  doaa  not  imply  partieular  default  settings;  these  must  ba  axplldtiy  stated  using  tha 
METAFLE  DEFAULTS  RB>LACEMB(r  aiamanL 

4.3.4.2  CQMEXTI  Category 

This  category  indudas  al  aiamants  dafirtad  for  tha  *ogm'  category  plus  tha  elamants  dafinad  for  tha  first 
addendum.  ^ 

4.3.4.3  OKSM  Category 

Tha  GKSM  category  dafinas  a  mataflla  which  conforms  to  tha  CGM  standard  and  indudas  alemants  to 
support  GKS,  IS  79^.  with  appropriate  raquiramants  relating  to  position  of  alamonts  in  tha  mataffla. 

P9g9l2 


Add  tha  follwoing  text  to  tha  and  of  sub-dausa  4.4.4 
MAXIMUM  VDC  EXTENT  dafinas  tha  space  into  which  tha  VDC  coordlnata  space  is  mapped  for  storage. 


PagmlS 


Add  tha  following  sub-clauses  aftar  sub-clausa  4.5.2: 

4.5.3  Davies  Control 

Tha  extended  CGM  may  contain  information  for  tha  interpreter  to  use  in  controlling  tha  output  of  tha 
graphical  information  stored  in  tha  metafile. 

4.5.4  Display  Surface  Concepts 

Display  surfaces  are  dassifiad  as  being  either  hard-copy  or  soft-copy,  on  tha  basis  of  tha  medium  that 
impiamants  tha  surface.  A  surface  that  is  hard  copy  is  implamantsd  by  means  of  a  medium  that  has  to  ba 
replaced  for  each  new  image.  One  that  is  soft-copy  is  implamantad  by  means  of  a  medium  that  may 
automaticaHy  ba  claarad  (typically  my  electrical  means)  for  each  new  image. 
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Examples  of  hard-copy  display  surfaces  are  found  in  storage  or  refreshed  cathode-ray  tubes  and  in  liquid 
crystal  cells. 

The  PREPARE  VIEW  SURFACE  function  is  used  to  ensure  that  the  medium  is  ready  to  accept  graphics  at 
the  start  of  a  page  or  frame.  K  has  a  parameter  that  permits  the  client  to  specify  that  a  hard-copy  device 
should  only  advance  the  medium  if  it  is  known  to  have  been  marked  upon  (to  conserve  expertsive  media)  or 
to  force  meda  advance  (for  example,  to  deliberatly  create  a  blank  frame  or  page  in  continuous  media)  This 
parameter  is  ignored  by  a  soft-copy  device,  which  always  dears  its  daplay  upon  receipt  of  this  command. 

4.5.5  Deferral  Mode  Concepts 

DEFERRAL  MODE  allows  the  storing  on  the  metafile  of  information  relating  to  the  control  of  buffering  and 
deferred  actions  of  a  graphics  system.  Deferral  mode  controls  the  possible  delaying  of  output  functions; 
for  example,  data  sent  to  a  device  may  be  buffered  to  optimize  data  transfer.  The  values  of  deferral  mode 
(in  increasing  order  of  delay)  are: 

a)  ASAP:  The  visual  effect  of  each  function  will  be  achieved  As  Soon  As  Possible  (ASAP). 

b)  BNI:  The  visual  effect  of  each  function  will  be  achieved  Before  the  Next  Interaction  (BNI). 

c)  ASTI:  The  visual  effect  of  each  furwtion  will  be  achieved  At  Some  Time  (ASTI). 


4.5.6  Devfea  Viewport  Control 

The  device  viewport  specifies  the  region  of  the  actual  device  viewsurfaee  into  which  the  VIX)  extent  is  to  be 
mapped. 

The  poeiflon  of  the  device  viewport  b  specified  in  one  of  three  unit  systems  selected  by  device  viewport 
specification  mode  parameters: 

by  fraction  [0.0  •  1 .0]  of  the  available  display  surfaoe,  which  allows  reasoruible  placement  arxl 
relative  sizii^  of  the  viewport  even  without  negotiation; 

In  millimetros  times  a  scale  factor,  which  aAows  absolute  sizing  of  images; 

in  physical  device  units. 

Artother  device  viewport  specification  mode  may  be  set  to  force  isotropic  mapping  even  if  the  speciTied  VDC 
extent  ar«t  device  viewport  would  not  otherwise  have  led  to  one.  In  such  a  case,  the  VDC  extent  is  mapped 
onto  a  subset  of  the  specified  device  vieport.  This  subset  is  defined  by  shrinking  either  the  vertical  or 
horizontal  dimension  of  the  specified  viewport  as  needed  to  reach  the  required  aspect  ratio.  This  smaller 
’effective  viewport*  is  then  used  to  define  the  coordinate  mapping  from  VDC  to  device  coordinates.  The 
placement  of  the  effective  viewport  rectangle  witNn  the  original  one  is  specified  by  the  third  arxf  fourth 
device  viewport  specification  mode  parameters:  the  options  are  left  edge,  right  edge.  o.  centred  when  the 
shrinking  is  horizontal,  and  top.  bottom  or  centred  when  it  is  vertical,  these  meanings  are  relativs  to  the 
norvinverted  viewport 

The  mappirtg  of  the  VDC  extent  to  the  device  can  be  minored  in  either  the  vertical  or  horizontal  direction  by 
reversing  either  the  x  or  the  y  values  in  the  device  vieport  specification.  This  implies  that  the  images  of  ail 
output  primitives  are  inverted,  irtcluding  text  and  markers. 


Pag»17 


Add  the  following  at  the  end  of  Clause  4.6.3.2 

The  font  list  can  be  modified  wKhin  a  picture  using  the  MODIFY  FONT  LIST  element.  This  allows  all  or  a  part 
of  the  list  to  be  modified. 

The  character  set  list  can  be  modfied  in  a  similar  way  using  the  MODIFY  CHARACTER  SET  LIST  element. 
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Add  th«  followring  sub-daus«s  aftsr  sub>c>aus«  4.6.7 
4.6.8  Cloaad  figuras 

Tha  CGM  as  axtandad  by  this  addandum  pravidas  tha  ability  to  construct  a  compound  primitiva  to  ba  fillad. 
by  a  saquanca  of  LINE  and  FILL  AREA  functions,  EDGE  attributas,  and  spacial  control  functions.  This 
compourxl  primitiva  or  constructad  ragion  is  rafarrad  to  as  a  ’closad  figura*.  and  is  randarad  using  the  same 
parity  (odd/avan)  flu  algorithm  as  used  for  other  fill  area  functions. 

The  dosed  figura  may  ba  constructad  of  a  combmation  of  straight  linas  and  curves  and  may  contain  *holas’ 
as  in  POLYGON  SET.  In  addition,  tha  capability  is  provided  to  specify  different  portioru  of  tha  edge  using 
different  EDGE  attributas. 


A  dosed  figura  is  daftr>ad  by  tha  fdlowing  functions: 


control  BEGIN  FIGURE 

functions:  BfO  FIGURE 

NEW  REGION 


MPLICIT  EDGE  VIS. 
ASF 

ESCAPE  (Note  1) 


boundary 

oonatnjdion 

functions: 


POLYUNE 

DISJOWTPOLYUNE 
CIRC.  ARC  3  PT. 

-^>>.AflCCTR 

C.RC.  ARC  CTR  BACKWARDS 

ELLIPTICAL  ARC 

GEN.  DRAWING  PRIM.  (Note  2) 


POLYGON 
POLYGON  SET 
CIRC.  ARC  3  PT.  CLOSE 
CIRC.  ARC  CTR.  CLOSE 
CIRCLE 

BJJPnCAL  ARC  CLOSE 

ELLIPSE 

RECTANGLE 


edge  attribute  BDGECOLOUR 

fiswtiorw:  EDGEWDTH 

SXSETYPE 


EDGE  BUNDLE  MDEX 
EDGE  VISIBILfTY 


Note  1 :  Whether  ESCAPE  has  meaning  with  regard  to  tha  construction  of  dosed  figures  Is 

dependant  on  tha  particular  escape  tunctionidantiflar. 

Note  2:  Whether  GENERALIZED  DRAWING  PRIMITIVE  has  meaning  with  regard  to  tha 

construction  of  dosed  figures  is  dependant  on  tha  particular  GDP  function  identifier. 


4.6.9  Pixel  Array 

Pixel  Array  is  similar  to  CELL  ARRAY  with  tha  exception  that  no  other  mapping  other  than  integer  scaling  of 
tha  array  elements  takas  place.  Tha  colour  information  in  tha  pixel  array  maps  diredly  to  the  pixels  of  the 
target  davica.  The  startirrg  point  arxi  colour  information  are  spadfied  in  a  device  independent  fashion,  but 
tha  appearance  of  tha  final  image  depends  directly  on  the  resolution  and  aspect  ratio  of  the  target  device  as 
an  MxN  array  of  device  indeperKfent  colour  specifiers  that  are  assigned  to  an  MxN  array  of  pixels. 


Page  22 

Sub-clause  4.7:  Add  the  following  immediatoly  above  sub-clause  4.7.1 : 

The  attribute  elements  LINE  REPRESENTATION.  MARKER  REPRESENTATION,  FILL  REPRESENTATION. 
EDGE  REPRESENTATION  and  TEXT  REPRESENTATION  are  used  to  set  all  of  the  attribute  values  in  a 
bundle  table  entry  at  the  same  time. 


Page  40 

Add  the  following  sub-dauses  after  sub-dause  4.1 1 ; 

4.12  S«gment  Elements 
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4.12.1  Introduction 


In  tho  CGM,  graphical  output  primitivas  and  attributa  satUng  alamants  may  ba  groupad  in  sagmanta  as  wall 
as  baing  mvokad  outsida  sagmants.  Each  sagmant  is  idanbfiad  by  a  uniqua  sagmant  idantifiar.  Sagmants 
may  ba: 

a.  transformad; 

b.  mada  visibla  or  invisibla; 

c.  Nghlightad; 

d.  ordarad  front  to  back; 

a.  mada  datactabla  or  undatactabla; 
f.  dalatad; 

within  a  pictura.  Thay  can  also  ba  dafirrad  as  Giobai  Sagmants  as  part  of  tha  Matafila  Dascriptor  ar>d  can 
than  ba  copiad  into  tha  pictura. 

Ortly  functions  storad  biaida  sagmants  ara  affaetad  by  thasa  oparations. 

Sagmmts  ara  tha  units  lor  manipulation  and  changa.  Manipulation  includas  craation.  daiation  and 
ranaming,  Changa  indudas  transforming  a  sagmant,  making  a  sagmant  visibla  or  invisibla,  Nghilghting  a 
sagmant,  and  changing  tha  ordar  of  ovarlapping  sagmants. 

appaaranca  of  sagmants  is  controlad  by  sagmant  attributaa,  which  induda  sagmant  transformation, 
visibility,  Mghiighting.  artd  sagmant  display  priority.  Such  sagmant  attributas  can  ba  a  basis  for  faadback 
during  manipuiatfora  (for  axampla,  highlighting).  Tha  pick  Input  propartias  of  sagmants  ara  also  oorttroilad 
by  sagmartt  attributas.  which  induda  datactabilHy  arxi  pick  priority. 

Tho  sagmant  alamants  ara: 

REOPefSEGMOfr 
COPYSEGMeiT 
DELErESECMBn- 
DELETE  ALL  SEGMenS 
RB4AMESEGM&fT 
REDRAW  ALL  SEGMENTS 
IMPLICrr  REGENERATION  MODE 
INHERITANCE  FILTER 
SEGMBTT  TRANSFORM 
SEGMENT  VISIBILITY 
SEGMENT  HK3HUGHT1NG 
SEGMENT  DISPLAY  PRIORITY 
SEGMBVT  DETECTABILnY 
SEGMBfT  PICK  PRIORITY 

4.12.2  Global  and  Local  Sagmants 

Thera  are  two  types  of  sagmants:  Local  Sagmants  and  Global  Sagmants.  Both  contain  primitives  and 
attributes  which  can  be  manipulated  in  tha  manner  dascribad  above.  Local  Segments  appear  within  a 
picture  and  ara  local  to  that  picture.  In  contrast  Global  Segments  can  ba  used  by  a  number  of  the  pictures  in 
(ha  matafila  in  which  thay  ara  defined. 

4.12.2.1  Location  of  and  Access  to  Global  Sagmants. 

A  Global  Segment  is  dalimitad  by  tha  normal  BEGIN  SEGMENT  and  END  SEGMENT  elements.  Global 
Segments  are  defined  in  the  Metafile  Descriptor.  Thay  are  not,  by  default,  defined  for  or  known  to  individual 
pictures  in  tha  metafile.  Thay  must  are  accessed  from  within  irtdividual  pictures  by  the  COPY  turKtion.  The 
effect  within  a  picture  of  a  COPY  function  referring  to  a  Global  Segment  is  identical  to  the  effect  of  a  COPY 
function  referring  to  a  Local  Segment. 
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4.1 2^.2  Allowable  Elamants  In  MO  and  GSD  States 


BEGIN  SEGMENT  and  END  SEGMENT  are  the  only  sagmant-faiatad  alamants  that  ara  allowad  witNn  tha 
Matafila  Descriptor  (MD)  state  (sea  Table  3(a).  tha  Metafile  State  Table).  All  of  tha  segment  attribute 
elements  may  occur  within  Global  Segment  Definition  (GSD)  state.  Tha  segment  control  elements 
REOPEN  SEGMENT.  DELETE  ALL  SEGMENTS,  and  REDRAW  ALL  SEGMENTS  ara  not  allowed  in  GSD 
state.  Otherwise  aU  of  the  segment  control  elements  are  allowed  in  GSD  state  (with  the  usual  restriction 
that  delete  may  not  refer  to  the  cunentty  open  segment).  COPY  is  allowed  in  GSD  state. 

A  number  of  other  control  elemerrta  are  prohibited  in  GSD  state.  These  are  elements  which  make  sense  in 
Local  Segment  Definition  (LSD)  state,  wfwn  a  picture  is  open,  but  which  would  not  make  sense  in  GSD  state, 
when  the  Metafile  Descriptor  is  being  processed.  DEVICE  VIEWPORT  is  an  example  of  such  a  control 
element  These  mles  are  concisely  presented  Table  3(a) 

4.12.2.3  References  to  Global  Segments 

Within  pictures,  no  elements  are  allowed  that  would  modify  the  contents  or  default  appearance  of  Global 
Segments.  This  includes  all  of  the  segment  control  elements  and  segment  attributes.  This  restriction 
preserves  logical  indeperxlence  of  pictures  and  the  ability  to  randomly  access  pictures.  The  only  allowable 
references  to  Global  Segments  within  pictures  are  via  the  COPY  furKtion. 

4.12.2.4  Attribute  Binding  of  Global  Segments 

Attributes  ara  bound  in  Global  Segments  as  they  are  in  Local  Segments.  Upon  the  occurance  of  BEGIN 
METARLE,  every  element  that  la  modally  daflrt^  and  bound  to  primitivas  (Metafile  Descriptor  elements 
defining  modes  and  precisions.  Picture  Descriptor  elements.  Control  elements,  arwl  Attribute  elements)  has 
a  wel  ^flned  value.  ConoaptuaHy  the  set  of  al  of  these  define  a  *Modal  Stata  Lisr. 

Tha  Metafile  Descriptor  la  processed  sequentially.  Throughout  the  Metafile  Descriptor,  modal  MD  elements 
modify  the  MO  entries  in  the  state  list  arsl  oocurrances  (posaA)ly  multiple)  of  the  METARLE  DEFAULTS 
REPLACEMENT  element  allow  manipuiation  (outside  of  (3S0  state)  of  all  of  the  rest  of  the  modal  elements 
(as  well  as  explicitly  changirtg  the  defaults).  Within  GSD  state  the  allowable  modal  elements  (control, 
attribute,  arxf  segment  attribute)  also  alter  the  oortterrts  of  the  Modal  State  List  The  values  of  modal 
elements  that  are  in  effect  upon  BEGIN  PICTURE  are  the  default  values,  whether  they  are  implicit  (defined  in 
the  Standard)  or  explidt  (i.e.,  via  the  Metafile  Defaults  Replacement). 

4.12.3  Creating  Segments 

4.12.3.1  Segment  Identifiers 

Each  segment  has  a  unique  identifier  associated  with  it.  Once  a  segment  is  deleted,  its  identifier  is  no  longer 
associated  with  the  segment  and  may  be  reused  for  another  segment  definition.  The  segment  identifier 
associated  with  a  closed  segment  may  be  changed  with  the  RENAME  SEGMENT  function.  Segment 
identifiers  are  of  type  SEGMENT  NAME.  The  segment  identifier  is  specified  with  the  BEGIN  SEGMENT 
function. 

The  supported  range  of  segment  identifiers  is  impiementation>dependent.  The  segment  identifier  is  used  by 
BEGIN  SEGMENT.  REOPEN  SEGMENT.  COPY  SEGMENT.  DELETE  SEGMENT.  RENAME  SEGMENT, 
REDRAW  SEGMENT,  arxf  all  segment  attribute  functions. 

4.12.3.2  Opening  and  Closing  Segments 


The  BEGIN  SEGMENT  function  is  the  only  means  of  creating  a  segment.  Once  a  segment  is  ooened.  the 
current  state  of  the  individual  primitive  attributes,  clipping  rectangle,  clip  indicator,  and  pick  identifier  are 
known  arxf  the  identifier  of  the  open  segment  is  set  in  the  Segmentation  State  List.  While  a  segment  is  open, 
the  graphical  objects  passing  along  the  CGI  pipeline  are  stored  in  the  segment.  Segment  attributes  are  also 
associated  with  the  segment  Once  open,  the  segment  remains  open  for  definition  until  END  SEGMENT. 

Segment  attributes  such  as  segment  visibility,  segment  highlighting,  arxf  segment  display  priority  affect  the 
appearance  of  the  display  and  may  be  set  either  while  the  segment  is  open  or  at  any  time  after  it  is  closed 
but  not  deleted. 
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A  ciosad  sagmant  may  b«  raopenad  at  a  latar  tima  with  tha  REOPEN  SEGMENT  function.  Whan  a  segment  is 
reopened,  graphical  objects  are  stored  in  tha  segment  using  the  same  concaptual  mechanism  as  when  a 
segment  is  initially  opened.  When  reopened,  ail  subsequent  graphical  objects  are  appended  to  the  open 
segment  until  END  SEGMENT. 

Consider  tha  following  example: 

UNE  COLOUR  (blue) 

BEGIN  SEGMENT  (1) 

POLYLINE 

UNE  COLOUR  (yelow) 

POLYLWE 
END  SEGMENT 
POLYLINE 


UNE  COLOUR  (red) 
REOP0I  SEGMENT  (1) 
POLYLINE 
BiO  SEGMENT 
POLYLINE 


blue  lines 
yellow  lines 
yellow  lines 

reopen  segment  1 
red  lines 

red  lines 


4.12.3.3  Graphical  Objects 

CGM  elements  may  be  grouped  to  conceptually  term  graphicai  objects.  Such  functions  consist  of  primitives, 
attributes,  and  oerUdn  corrtrol  eapabifltles.  Refer  to  Table  XX  for  a  list  of  primitives,  attributes,  and  control 
which  oonoeptually  may  be  used  to  form  graphicai  objects. 

The  state  list  given  later  in  this  clause  details  those  elements  which  are  allowed  in  the  segement  open  state 
for  both  local  arxl  globai  segments. 

TABLE  XX  Rincliona  used  to  form  Graphicai  Objects 


Primitives: 

POLYUNE 

DfSJOWTPOLYUNE 

POLYMARKffl 

POLYGON 

POLYGON  SET 

RECTANGLE 

CIRCLE 

ELLIPSE 

CIRC.  ARC  3  POINT 
CIRC.  ARC  3  POINT  CLOSE 
aRC.  ARC  CBITRE 
CIRC.  ARC  CENTRE  CLOSE 
CIRC.  ARC  CENTRE  BACKWARDS 


BJJPRCAL  ARC 
BJJPTTCAL  ARC  CLOSE 
TEXT 

APPBf  D  TEXT 
RESTRICTED  TEXT 
CELL  ARRAY 
BEGIN  RGURE 
END  RGURE 
NEW  REGION 
GENERALIZED  DRAWING 
PRIMITIVE  (GDP) 

PIXEL  ARRAY 
ESCAPE  (Note  1 ) 


Attributes  and  Control  Capabilities: 

AUXILIARY  COLOUR 

DRAWING  MODE 

TRANSPAR04CY 

UNE  BUNDLE  INDEX 

UNE TYPE 

UNE  WIDTH 

UNE  COLOUR 

MARKER  BUNDLE  INDEX 

MARKER TYPE 

MARKER  SIZE 

MARKER  COLOUR 

RLL  BUNDLE  INDEX 

RU.  COLOUR 

RLL  REFERENCE  POINT 


EDGE  BUNDLE  INDEX 

EDGE  TYPE 

EDGE  WIDTH 

EDGE  COLOUR 

EDGE  VISIBILITY 

IMPLICIT  EDGE  VISIBILITY 

CHAR.  SET  INDEX 

CHAR.  EXPANSION  FACTOR 

CHAR.  COOING  ANNOUNCER 

CHAR.  SPACING 

CHAR.  HEIGHT 

CHAR.  ORIENTATION 

ALTERNATE  CHAR.  SET  INDEX 

TEXT  BUNDLE  INDEX 
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WTERIOR  STYLE 
HATCH  INDEX 

PATTERN  NDEX 
PATTERN  SIZE 


TEXT  PRECISION 
TEXT COLOUR 
TEXT  PATH 
TEXTAUGNMBn’ 
ASPECT  SOURCE  FLAGS 
CUP  RECTANGLE 
CLIP  INDICATOR 
PICK  IDENTIRER 


NOTE:  whether  or  not  ESCAPE  is  a  graphical  object  depends  on  the  escape  identifier,  and  is 
implementation-<ls  pendent. 


4.12.3.4  Non>Retalned  Data 

Any  graphical  object  passing  along  the  pipeline  when  no  segment  is  open  becomes  non-retained  data.  The 
data  is  displayed  in  the  usual  manner.  However,  it  is  never  redrawn  as  a  result  of  implicit  or  explicit  segment 
dbpiay.  In  particular,  functions  such  as  REDRAW  ALL  SEGMENTS  will  not  redraw  data  which  has  not  been 
stored  in  a  segmenL 

4.12.4  Segment  Attributes 

4.12.4.1  Introduction 

The  segment  attributes  associated  with  each  segment  control  display  and  pick  input  prepertlos.  Segment 
attributes  can  be  set  either  while  the  segment  Is  open  or  any  time  after  tt  is  dosed  but  not  deleted.  When  a 
segment  is  opened  with  the  BEGIN  S^MENT  function,  the  segment's  attributes  are  set  to  their  default 
values. 

Each  of  the  segment  attributes  are  discussed  in  detail  in  the  remaining  parts  of  this  section. 

Segment  attributes  are  assodated  wHh  the  segment  rather  than  the  segment  ktentHter.  This  means  that  all 
segment  attributes  no  longer  exist  for  the  segment  when  ft  is  deleted.  This  also  means  that  the  segment 
attributes  are  not  changed  when  a  segment  is  renamed. 

4.12.4.2  Segment  Highilghting 

Segment  highlighting  has  two  states,  NORMAL  and  HIGHLIGHTED.  The  setting  of  this  attribute  selects  one 
of  these  two  states  for  the  segment.  The  nature  in  which  highlighting  is  represented  is  implementation- 
dspendenL  When  a  segment's  highlighting  attribute  is  changed,  all  of  the  graphical  objects  of  the  segment 
are  displayed  based  on  the  implicit  segment  regerwration  mode  and  the  segment  display  priority. 

4.12.4.3  Segment  Visibility 

Segment  visibility  can  be  set  to  VISIBLE  or  INVISIBLE.  When  a  segment  is  set  to  be  VISIBLE,  all  of  the 
graphical  objects  are  displayed  based  upon  the  implicit  segment  regeneration  mode  and  the  segment 
display  priority.  A  segmerrt  can  be  picked  only  if  it  is  both  VISIBLE  aixi  DETECTABLE. 

4.12.4.4  Segment  Detectability 

A  segment  can  be  set  to  be  DETECTABLE  or  UNDETECTABLE.  A  segment  can  be  picked  only  if  it  is  both 
VISIBLE  and  DETECTABLE.  Segment  detectability  does  not  affect  the  display  or  appearaiv:e  of  segments. 

4.12.4.5  Segment  Display  Priority 

The  segment  display  priority  attribute  determines  how  overlapping  segments  are  displayed.  In  general, 
segments  with  higher  display  priorities  will  be  displayed  as  if  they  were  in  front  of  segments  with  lower 
display  priorities. 


The  SEGMENT  DISPLAY  PRIORITY  function  is  used  to  change  the  display  priority  of  a  segment.  When  a 
segment's  display  priority  is  changed,  the  segments  display  is  based  on  the  implicit  segment  regeneration 
mode  ard  the  new  display  priority. 


4.12.4.6  Sagmant  Pick  Priority 


Each  sagmant  has  an  associatad  pick  priority.  The  pick  priority  is  usad  to  rasolva  tha  picking  of  sagmants 
which  ovarlap.  if  two  or  mora  sagmants  overlap  arxf  tha  pick  location  is  within  the  intersection  of  these 
sagmants,  the  segments  picked  will  tM  orre  or  more  of  those  with  the  highest  pick  priority.  If  mora  than  one 
of  the  overlapping  segments  has  the  highest  pick  priority,  then  the  segments  picked  will  tie  the  segments 
with  both  the  highest  pick  priority  arxi  highest  and  display  priority.  In  such  cases  a  list  of  segment  identifiers 
is  returned  with  the  identical  and  highest  pick  priorities  and  display  priorities. 

4.12.4.7  Segment  Transform 

Tha  sagmant  transform  Is  a  coordinate  transform  associated  with  each  sagmant.  It  allows  scaling, 
translation,  and  rotation  of  sagmants. 

Note  that  the  segment  transform  is  distinct  from  the  VOC  EXTEMT/DEVICE  VIEWPORT  mapping,  which  is  a 
transform  of  VOC  space  to  OC  space.  Tha  sagmant  transform  is  a  transform  of  VOC  space  to  VOC  space. 

Tha  sagmant  transform  is  appliad  to  rafararrca  points  and  paramoters  and  attributas  with  significance  in  VOC 
space.  Tha  reference  points  are  dafinad  to  be  ail  input  parameters  of  type  POINT.  Parameters  with 
significance  in  VOC  space  irKkide  the  radius  of  a  CIRCLE.  Attributes  with  significance  in  VOC  space  irwiuda 
scalars  such  as  PATTERN  SIZE  CHARACTER  ORIENTATION,  and  LINE  WIOTH,  EOGE  WIOTH  and 
MARKER  SIZE  whan  they  are  spacHiad  in  VOC.  Other  attributes  which  may  be  transformad  irKiuda 
CHARACTER  HBGHT  and  RU.  RB^e«:E  PaNT. 

Transformation  of  tha  radius  of  a  CIRCLE  is  avaluatad  by  transforming  a  radius  vector  alignad  in  an 
impiamantation*  dependant  manner.  Similarly.  If  a  rotation  transform  ware  appliad  to  a  RECTAf^LE  the 
comers  of  tha  RECTANGLE  will  chartga,  but  tha  edges  of  t^la  ractangla  wfll  remain  horizontai  and  vertical.  If 
a  scaling  transform  is  appliad  to  a  PiX^  ARRAY,  tha  location  of  tha  PIXEL  ARRAY  changes,  bul  not  Ns 
stza.  If  a  trarrsform  b  appliad  to  RESTRICTEO  TEXT,  its  rafaranca  points  arc  changed.  That  is.  Its  location 
arxi  its  extant  will  change. 

Whan  tha  mapping  of  tha  VOC  space  to  device  or  visual  space  is  anisotropic,  due  either  to  a  sagmant 
transform  or  tha  VOC  EXTENT.  DEVICE  VIEWPORT,  and  DEVICE  VIEWPORT  MAPPING,  thick  fines  may  be 
rendered  In  aither  of  two  ways: 

A  uniform  transformation  may  be  applied,  such  that  the  thick  line  behaves  as  would  a  polygon 
equivaient  to  the  two-dimensional  realization  of  the  thick  line.  In  this  case,  the  rendered  width  of 
the  line  will  change  with  tha  drection  of  the  line  segment. 

•  A  fixed  scaling  may  be  selected  which  is  between  the  minimum  (scale  in  X,  scale  in  Y)  and 

maximum  (scale  In  X  scale  in  Y).  and  applied  to  all  line  segments  independent  of  th^r  direction. 

The  rendering  of  markers  is  intended  not  to  be  transformed  by  either  anisotropic  mapping  established  by 
VOC  EXTENT  and  related  commarxfs,  nor  by  the  segment  trarrsform.  That  is.  the  shape  of  the  marker 
symbol  is  not  to  be  aKered. 

When  MARKER  SIZE  is  specified  in  VOC  units,  the  MARKER  SIZE  is  converted  into  a  vector  and 
transformed;  a  single  scale  factor  between  the  minimum  (scale  in  X  ,  scale  in  Y)  and  maximum  (scale  in  X. 
scale  in  Y)  is  selected  aixf  applied  uniformly. 

A  segment  transform  is  represented  by  a  2x3  matrix,  composed  of  a  2x2  scaling  and  rotation  portion,  and  a 
2x1  translation  portion.  The  detauft  segment  transform  is  represented  by  the  identity  transform.  If  the  user 
never  invokes  the  SEGMENT  TRANSFORM  furrction,  then  all  coordinate  data  is  mapped  the  same  as  non- 
retained  data  (i.e.,  the  VOC  EXTENT/OEVICE  VIEWPORT  is  the  only  mapping).  If  the  user  alters  the 
segment's  transform  attribute,  each  of  the  reference  points  discussed  previously  will  be  transformed  by  the 
segment  transform,  producing  new  data. 

The  segment  transform  is  a  segment  attribute.  This  transform  may  be  modified  by  the  SEGMENT 
TRANSFORM  function.  The  stored  transform  is  applied  each  time  the  segment  is  redrawn.  Setting  the 
transform  back  to  identity  will  produce  the  original  picture  with  no  loss  of  data  on  the  next  redraw. 

The  use  of  segment  transforms  may  produce  coordinates  that  cannot  be  expressed  within  the  VOC  range. 
This  is  handled  in  an  implementation-dependent  way. 
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Th«  s«qu«nc«  of  transforms  is  optionally  tha  copy  transform  followad  by  tha  sagmant  transform,  than  dip  to 
a  clipping  araa,  foUowad  by  tha  VDC  EXTENT/D^iCE  VIEWPORT  transform.  non-ratainad  data  thara  is 
no  sagmant  transform.  Fix  data  storad  In  sagmants.  tha  sagmant  transform  maps  VDC  to  VDC.  Clipping 
ractangias  ara  not  transformad  by  tha  sagmant  transform.  Tha  last  transform,  VDC  EXTENT/DEVICE 
VIEWPORT,  Is  finally  appiiad  to  map  VDC  to  DC. 

4.12.5  Sagmant  Display 

4.12.5.1  Introduction 

Sagmant  display  is  tha  procass  which  produces  a  visibla  image  on  a  display  surface  from  tha  graphical 
objects  in  a  sagmant.  Sagmants  can  always  be  displayed,  individually  or  collactivaiy,  by  tha  explicit 
invocation  of  REDRAW  SEGMBTT,  or  REDRAW  ALL  SEGMEhTTS.  Sagmants  can  also  ba  displayed 
implicitly,  under  soma  circumstances,  without  using  tha  above  functions. 

Several  of  tha  sagmant  attributas  affect  sagmant  display.  Sagmant  highflghtirtg  datarminas  how  a  segment 
is  displayed.  It  can  be  sat  to  NORMAL  or  HIGHLIGHTED.  Sagmant  visibility  datarminas  whether  the 
graphical  objects  within  a  sagmant  are  dspiayabia.  It  can  ba  sat  to  VISIBLE  or  INVISIBLE.  Segment  display 
priority  datarminas  which  overlapping  segments  appear  to  ba  in  fronL  Sagmarrt  transform  affects  tha 
position,  size,  and  orientation  of  tha  displ^ad  sagmant.  Sagmant  detectability  is  a  sagmant  attribute  that 
affects  the  capability  of  a  sagmant  to  ba  pMad. 

Prfmitiva  attributes  which  ara  conceptually  part  of  tha  graphical  objaefs  definition  also  affect  tha 
appearance  of  tha  displayed  sagmanL 

4.12.5.2  Sagmant  Raganaratlon 

Implicit  sagmant  ragartaration  mode  datarmirMS  whan  picture  changes  occur.  Operations  not  immediately 
supported  by  devices  may  require  certain  functions  to  perform  an  impildt  ragartaration.  For  axampia,  it  is 
poairibla  to  create  a  sagmant  and  than  modfy  one  of  tha  sagmant  attributas  which  could  causa  the  picture 
to  change.  Soma  davicas  such  as  plotlsra  ara  only  eapabia  of  doing  addMva  output  as  Is  tha  case  with  no 
segmentation.  For  axampia,  K  such  a  davioa  racaivad  a  function  to  chartga  tha  sagmant  transform,  than  it 
would  have  to  advance  tha  paper  or  fHm  and  ragartarata  tha  entire  picture.  In  order  to  prevent  tha  waste  of 
time  and  paper,  tha  CGM  as  extended  by  this  addendum  has  an  tMPUCfT  S&SMENT  REGENERATION 
MODE  function. 

Tha  IMPLICIT  SEGMENT  REGENERATION  MODE  function  may  ba  used  to  stop  such  implicit  actions  from 
occurring  immadlataly.  If  tha  mode  is  sat  to  SUPPRESSED  than  no  implicit  raganaration  occurs.  It  is  than  up 
to  tha  user  to  decide  whan  tha  picture  is  oomplata.  At  that  time  tha  user  explicitly  invokes  tha  PREPARE 
VIEW  SURFACE  and  REDRAW  ALL  SEGMENTS  functions. 

Tha  implicit  sagmant  raganaration  mode  should  ba  SUPPRESSED  on  davicas  which  must  perform  a 
raganaration  to  display  the  result  of  sagmant  changes.  Tha  default  setting  of  implicit  raganaration  mode  is 
SUPPRESSED. 

It  should  ba  noted  that  not  all  functions  causa  implicit  raganaration.  Tha  actions  which  may  causa  implicit 
raganaration  irwluda  changing  sagmant  attributas  such  as  sagmant  display  priority,  segment  visibility, 
sagmant  highlighting  and  sagmant  transform.  In  addition,  if  a  sagmant  is  open  and  the  implicit  sagmant 
raganaration  mode  is  sat  to  ALLOWED,  raganaration  may  taka  place  as  graphical  objects  ara  added  to  the 
segment  The  impficit  segment  regeneration  mode  merely  suppresses  or  allows  raganaration. 

Sattirig  tha  mode  to  SUPPRESSED  does  not  martdata  that  picture  changes  ara  suppressed.  It  merely  stops 
devices  from  regenerating  the  picture  if  tha  device  uses  implicit  raganaration  as  tha  method  for 
implementing  some  CGM  elements.  If  the  intention  is  to  delay  the  visual  effect  of  output  than  tha  SEGMENT 
VISIBILfTY  function  should  ba  used.  Implicit  sagmant  regeneration  should  not  be  confused  with  deferral 
mode.  Segment  regeneration  takes  precederKe  over  the  deferral  mode. 

4.12.5.3  Implicit  Segment  Display 

When  implicit  segment  regeneration  mode  is  ALLOWED,  segments  may  be  regenerated  implicitly.  Implicit 
segment  regeneration  may  happen  initially  as  tha  segment  is  being  defirted.  Closed  segments  may  also  be 
regenerated  implicitly  to  maintain  a  current  image  on  the  display  surface.  In  this  latter  case,  implicit 
regeneration  would  typically  happen  when  interpretation  of  a  CGM  element  changes  the  appearance  of  the 
displayed  image  in  some  respect.  For  example,  implicit  regeneration  may  ba  required  when  changing  the 
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display  priority  of  a  segmant.  It  may  also  ba  raquirad  whan  changing  lha  sagmant  transform,  sagmant 
visibility,  and  sagmant  higNighting  attributas. 

4.12.5.4  Explicit  Sagmant  Display 

Tha  alamants  REDRAW  SEGME?^  and  REDRAW  ALL  SEGMENTS  can  ba  usad  axpHcitly  to  display  visibla 
sagmants,  irxlaparxlant  of  tha  implicit  sagmant  raganaration  moda.  REDRAW  ALL  SEGMENTS  displays  all 
dafinad  visibla  sagmants  without  daaring  tha  display  surtaca.  REDRAW  SEGMENT  draws  tha  sagmant 
idantifiad.  It  is  implamantatiorvdapartdant  whathar  sagmants  that  ovariap  tha  kfantifiad  sagmant  ara  also 
radrawn  with  tha  REDRAW  SEGMENT  function.  REDRAW  SEGMENT  and  REDRAW  ALL  SEGMENTS  ara 
most  usaful  whan  tha  implicit  sagmant  raganaration  moda  is  sat  to  SUPPRESSED. 

4.12.6  Copy  Sagmant  and  tha  Inharltanca  FIttar 

Tha  COPY  SEGMENT  function  oopias  tha  graphical  objacfs  in  tha  idarT«iad  sagmant  into  tha  opan  sagmant. 
applying  a  coordinata  transformation  as  tha  objacts  ara  coptad. 

Tha  objacts  copiad  may  ba  altarad  in  a  variaty  of  ways: 

a.  Tha  inharitanca  flHar  controls  whathar  individual  attributa  valuas  ara  raappliad  to  tha  graphical 
objacts 

b.  Tha  graphical  objacts  ara  transformad  by  tha  copy  sagmant  transfonnatlon  according  to  tha  rulas 
for  transformation 


An  axampia  of  tha  COPY  SEGMENT  fun^lon  is  as 

foflows: 

LINE  COLOUR  (bkia) 

BEGIN  SEGMBTT  (1) 

LINE  STYLE  (dotted) 

POLYUNE 

blua  dottad  Bna 

ENOSEGMBfT 

LINE  COLOUR  (rad) 

UNE  STYLE  (dashed) 

BEGIN  SEGMB4T  (2) 

POLYLWE 

rad  dashed  lino 

COPY  SEGMENT  (1) 

tha  copy  of  sagmant  (1) 

POLYLINE  still  ganoratas 
a  blua  dottad  line,  unless 
changed  with  tha  inharitartce 
filter. 

Tha  CGM  ganarator  has  tha  capability  of  satting  a  copy  transform.  Tha  copy  sagmant  transform  is  appliad  to 
graphical  objacts  bafora  thay  ara  copiad  info  tha  opan  sagmant  Howavar.  this  doas  not  apply  to  clipping 
ractangias.  Graphical  objacts  may  ba  transformad  to  altar  tha  location,  tha  siza.  and  tha  oriantation  of 
primitivas. 

An  axampia  of  tha  COPY  SEGMENT  function  with  tha  INHERITANCE  RLTER  function  is  as  follows: 


INHERITANCE  RLTER  (UNE  ATTRIBUTES,  STATE_LIST) 


BEGIN  SEGMENT  (1) 
UNE  COLOUR  (Wua) 
LINE  STYLE  (dottad) 
POLYLINE 
END SEGMENT 
UNE  STYLE  (dashed) 
UNE  COLOUR  (red) 
BEGIN  SEGMENT  (2) 
POLYLINE 
COPY  SEGMENT  (1) 


blue  dottad  line 


rad  dashed  line 

red  dashed  line  since  the 

inheritance  filter  selects 


STATE_LIST  lor  line  attributes. 


4.12.7  Oalata  and  Ranama  Sagmants 


« 
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Th«  DELETE  SEGMENT  function  is  used  to  del«t«  an  individual  sagmant.  Ukawisa,  tha  DELETE  ALL 
SEGMENTS  function  dalatas  ail  sagmants.  Sagmant  idantifiars  for  sagmants  which  hava  baan  dalatad  ara 
immadlataly  availabla  for  rausa. 

If  an  attampt  is  mada  to  daiata  tha  opan  sagmant.  aithar  by  DELETE  SEGMENT  or  by  DELETE  ALL 
SEGMENTS,  an  arror  is  datactad  and  tha  furKtion  is  ignored. 

Whan  a  sagmant  is  dalatad  it  is  erased  from  tha  display.  This  action  might  be  delayed  by  tha  implicit 
sagmant  raganaration  mode.  Delated  sagmants  may  be  erased  by  rrot  redrawing  them  at  tha  next 
raganaration.  Delating  a  sagmant  can  causa  an  implicit  raganaration  if  such  is  ailowad. 

An  existing  sagmant  may  be  renamed  at  any  time,  except  whan  opan.  (Whan  a  sagmant  is  rsrwmad  it  is 
immadiafaiy  associatsd  with  a  new  sagmant  idantifiar.)  Tha  segment's  old  idantifiar  is  immediately  availabla 
for  rausa  by  BEGIN  SEGMENT. 

4.12.8  Sava,  Restore  and  Oalata  Attributes 

Three  functfons  ara  provided  to  save  arxf  restore  attributes.  This  capability  allows  tha  diant  to  preserve  tha 
state  of  aB  primitivo  atthbutos,  excluding  bundle  tables,  character  sat  Kst.  font  list  colour  table,  and  pattern 
table  in  a  'namad*  area.  TNs  capability  can  be  used  to  save  and  restore  attributes  in  cor^unction  with 
opanirtg  and  dosing  sagmants. 
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Add  tha  fbflowing  to  Figure  12: 
figure  12  modi(icatior>s  to  add  sagmants 
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Add  tha  following  table  foilowing  tha  state  diagram 

Table  3(a)  CGM  Elements  by  their  allowed  states 


CGEM 

Element 


CGEM  states 

PC  MO  GS  PO  PO  TO  LS  FC  FO 


BEGIN  PICTURE 
BEGIN  PICTURE  BODY 
END  PICTURE 
BEGIN  SEGMENT 
END  SEGMENT 
END  METAFILE 


X 


METAFLE  VERSION  X 

METARLE  DESCRIPTION  X 

VOC  TYPE  X 

INTEGER  PRECISION  X 

REAL  PRECISION  X 

INDEX  PRECISION  X 

COLOUR  PRECISION  X 

COLOUR  INDEX  PRECISION  X 

MAXIUMUM  COLOUR  INDEX  X 

COLOUR  VALUE  EXTENT  X 
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METAFILE  ELEMENT  LIST  X 

METAFILE  DEFAULTS  REPL.  X 

FONT  LIST  X 

CHARACTER  SET  LIST  X 

CHAR  COOING  ANNOUNCER  X 

METAFILE  CATEGORY  X 

MAXIMUM  VOC  EXTENT  X 

SEGMENT  PRIORITY  EXTeiT  X 


SCALING  MODE 
COLOUR  SaECTION  MODE 
UNE  WIDTH  SPEC  MODE 
MARKER  SIZE  MODE 
EDGE  WIDTH  SPEC  MODE 
VOCEXT^IT 
BACKGROLff^  COLOUR 
VOC  INTEGER  PRECISION 
VDC  REAL  PRECISION 
AUXILIARY  COLOUR 
TRANSPAReiCY 
CUP  RECTANGLE 
CLIP  INDICATOR 
DEVICE  VIEWPORT 
DEVICE  VIEWPORT  MAPPING 
DEVICE  VPORT  SPEC  MODE 
D0=ERRALMOOE 
MAKE  PICTURE  CURRen* 
PREPARE  VIEW  SURFACE 
UPDATE 

MODIFY  FONT  LIST 
MODIFY  CHARACTER  SET  UST 


BEGIN  FIGURE 

END  FIGURE 

NEW  REGION 

IMPLICrr  EDGE  VISIBILITY 

SAVE  PRIMITIVE  ATTRIBUTES 

RESTORE  PRIMITIVE  ATTRBS 

DELETE  PRIMITIVE  ATT  SET 


X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 


X 

X 

X 


POLYLINE 
DISJOINT  POLYUNE 
POLYMARKER 
TEXT 

RESTRICTH)TEXT 
APPEND  TEXT 
POLYGON 
POLYGON  SET 
CQl  ARRAY 
GOP 

RECTANGLE 

CIRCLE 

CIRCUVRARC3POINT 
CIRCULAR  ARC  3  FT  CLOSE 
CIRCULAR  ARC  CENTRE 
CIRC  ARC  CENTRE  CLOSE 
ELLIPSE 
ELLIPTICAL  ARC 
B.LIPTICAL  ARC  CLOSE 
CIRC  ARC  CENTRE  BKWDS 
PIXEL  ARRAY 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


LINE  BUNDLE  INDEX 
UNE  TYPE 


XXX 

XXX 


■ 
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UNE  WIDTH 
UNE  COLOUR 
MARKER  BUNDLE  INDEX 
MARKER TYPE 
MARKER  SIZE 
MARKER  COLOUR 
•reXT  BUNDLE  WDEX 
TEXT  FONT  WDEX 
TEXT  PRECISION 
CHAR  EXPANSION  FACTOR 
CHARACTER  SPACING 
TEXT  COLOUR 
CHARACTER  HEIGHT 
CHARACTER  ORIB^ATION 
TEXT  PATH 
TEXTAUGNMBIT 
CHARACTBT  SET  INDEX 
ALT  CHAR  SET  INDEX 
FILL  BUNDLE  INDEX 
INTSTIOR  STYLE 
FILL  COLOUR 
HATCH  MDEX 
PATTeiN  INDEX 
EDGE  BUNDLE  INDEX 
EDGE TYPE 
S3GE  WIDTH 
EDGE  COLOUR 
EDGE  VISIBILITY 
FILL  REFfflBJCE  POINT 
PATTERN  TABLE 
PATTERN  SIZE 
COLOUR  TABLE 
ASPECT  SOURCE  FLAGS 
LPC  REPRESENTATTON 
MARKER  REPRESENTATION 
TEXT  REPRESENTATION 
FILL  RB>RESENTATION 
EDGE  REPRESENTATION 
DRWAINGMODE 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 


X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
XXX 
XXX 
XXX 
XXX 
XXX 
XXX 
XXX 
X  X 
X  X 
X  X 
XXX 
XXX 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 
X  X 


X 

X 

X 

X 

X 


X 


X 

X 

X 

X 

X 


X 


ESCAPE 


XXX 


X  X  X  X 


X 


X 


MESSAGE 
APPLICATION  DATA 


XXX 

XXX 


X  X  X  X  X  X 
XX  XXX 


REOPB4  SEGMENT 
RENAME  SEGMENT 
DB-ETE  SEGMENT 
DELETE  ALL  SEGMENTS 
REDRAW  Aa  SEGMENTS 
COPY  SEGMENT 
IMPLICIT  SEG  REGEN  MODE 
INHERITANCE  FILTER 


X 

X 


X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 


SEGMBIT  TRANSFORM 
SEGMENT  VISIBILITY 
SEGMBfT  HIGHLIGHTING 
SEGMENT  DISPLAY  PRIORITY 
SEGMENT  PICK  PRIORITY 
SEGMENT  DETECTABILITY 


X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 
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PC  Pictur0  Clo3«d 

MD  Mclaftls  Dsscriptor 


XX  xxxx  xxxxxx 


GS 

Globai  Sagmant 

PO 

Pictura  OMcriptor 

PO 

PIctura  Opan 

TO 

TaxtOpan 

LS 

Local  Sagmant 

PC 

RguraClosad 

FO 

R^a  Opan 

P^42 

Sub-cteuM  5.1 :  Add  the  following  aftor  th«  ninth  paragraph  which  starts  with  tha  santanca:  ’Tha 
Extamal  Bamants....*: 

Tha  Sagmant  Bamants  (daacribad  In  sub-dausa  5.10)  provida  for  tha  grouping  and  manipulation  of 
alamants. 
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Sub-dausa  5.1 :  Add  tha  foliowing  at  tha  and  of  tha  tabla  of  abbraviations  of  data  typa  namas: 


N 

Narrw 

Idantifiar  of  typa  Intagar 

OP 

Daviea 

Point 

A  point  axprassad  in  a  ooordlnata  systam  that 
is  daviea  daparxlant  DP  units  ara  matras  or 
othar  appropriata  daviea  units. 

ASN 

Atiributa 

SatNama 

idsntffication  of  a  sat  of  vaiuas  usad  with 

SAVE  and  RESTORE  PRIMITIVE  ATTRBUTES 

SN 

Sagmant 

- 

IWRW 

Sagmant  IdantHlar 

RaaRzafton  ia  anooefing  dapandantRanga  is  hnplamantation  dap. 

VSP 

Viawport 

Spadfication 

Point 

Two  valuas  raprasanting  tha  x  and  y  ooonAnatas  of  a  point  In 
viawport  spadfication  spaca,  whosa  data  typa  and  hitarpratalion 
dapand  on  DEVICE  VIWPORT  SPECIFICATION  MODE. 

Paga4e 


Add  tha  foHowirtg  sub-dausas  aftar  sub-dausa  5.2.5: 

5^6  BEGIN  SEGMENT 
Paramatars: 

Sagmant  Idantifiar  (SN) 

Daserlptlon: 

This  is  lha  first  alamant  of  a  sagmant.  All  subsaquant  alamants  until  tha  naxt  END  SEGMENT  will 
ba  coilactad  into  this  sagmant. 

5.2.7  END  SEGMENT 
Paramatars: 

Nona 

Daserlptlon: 

Subsaquant  alamants  will  no  longar  ba  part  of  a  sagmant. 


« 
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Add  th«  following  at  tha  and  of  tha  Doscription  soction  of  sub-clausa  5.3.1 
Tha  CGM  as  sxtondad  by  Addandum  1  is  vorsion  two  (2). 


PagaSO 


Sub-clausa  5.3.11 :  Add  tha  following  shorthand  nama  at  tha  and  of  tha  list  givan  in  tha  sacond 
paragraph  of  tha  'Doscription*: 


GKSMO 


PagaSI 


Add  tha  following  nots  at  tha  and  of  sub-dausa  5.3.3:  FONT  LIST 
NOTE:  It  is  rsoommondod  that  a  dsnsa  font  list  Is  usod. 


PagaSS 

Add  tha  folowing  sub-dausos  aftor  sub-dausa  5.3.1 5: 

8.3.16  METAFILE  CATEGORY 
Paramatsra: 

cotsgory  (onaol:  cgm,  gksm,  cgmaxtl)  (E) 

Dsserlptlon: 

This  function  sots  tha  mataHla  catogory  to  tha  typo  indicatad  by  tha  paramator. 


8.3.17  MAXIMUM  VOC  EXTENT 

Paramatars: 

low  volua  (Point) 

high  volua  (Point) 

Dsserlptlon: 

Tha  paramatars  dafina  a  mapping  of  a  sub-spaca  of  tha  VOC  ranga  dafinod  by  (low, low)  and 
(high.high)  arsl  tha  virtual  ooordinata  spaca  of  a  graphics  systo'^,  a.g.  NDC,  such  that  the 
(I0W.I0W)  comor  is  oquivalant  to  tha  iowar  loft  corrwr  of  NDC.  and  tha  (high.high)  cornar  with  the 
upper  right  comor  of  NDC.  Tha  low  volua  is  lass  than  tha  high  valua. 


8.3.18  SEGMENT  PRIORITY  EXTENT 

Paramatars: 

minimum  extant  (intogar) 
maximum  axtant  (integer) 

Description: 

The  paramatars  raprasant  an  extant  which  bounds  the  segment  display  priority  values  which  will  be 
found  in  the  metafile.  It  need  not  represent  the  exact  extant  of  the  values  contained  in  the 
matafile. 


« 
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Add  th«  foUowIng  sub-dauscs  after  sub-dausa  5.S.6: 

5.5.7  DEVICE  VIEWPORT 

Paramatars: 

first  comar  (OP) 
saoond  comar  (DP) 

Daaerlptlon: 

Tha  two  paramatars  daflrw  tha  opposita  comars  of  a  ractanguiar  viewport  on  the  davica's  display 
surface. 

5.5.8  DEVICE  VIEWPORT 
Paramatars: 

VSUapac8iar 


Metric  seafa  factor 
Daaerlptlon 

This  function  datarminas  how  subsequent  functions  using  tha  data  type  VSU  (viewport 
apadflcaiion  unit)  or  VSP  (viewport  spadfication  point)  w8l  be  dafkiad.  (This  appias  primariiy,  but 
not  axdualvaly  to  tha  DEVICE  VIEWTORT  function.) 

These  paramatars  may  be  spadfiad  in  one  ol  three  systems  of  units. 

Whan  tha  first  parameter  is  fraction  of  default  davica  viewport tha  value  (0.0, 0.0)  corresponds  to 
tha  lower  left  oorrwr  and  tha  vaiua  (1.0. 1.0)  conasponds  to  tha  upper  comer  of  tha  default 
viewport  (Tha  default  davfoa  viawport  fs  tha  largest  unrotatad  rectangular  area  vidbia  on  tha 
display  surface.)  Numbers  outside  of  tha  range  [0.0..1.0]  may  be  spacifiad  (see  DEVICE 
VIEWTORT).  Tha  second  parameter  is  ignored. 

Whan  tha  parameter  is  'mlMmatras  with  scaiafactor*.  tha  metric  scale  factor  parameter  represents 
tha  dstartoa  (In  mHRmatras)  on  tha  view  surface  corresponding  to  one  VSU.  One  VSU  represents 
ona  miilimatra  muttipHad  by  tha  metric  scale  fador.  Tha  vaiua  (0.0)  corresponds  to  tha  lower  left 
corrtar  and  tha  values  increase  positivaly  to  tha  right  and  upwards. 

Whan  tha  parameter  is  'physical  davica  units',  tha  native  units  and  handedness  of  tha  physical 
davica  are  used.  Tha  saoond  parameter  is  ignored. 

Note  •  Metric  scaling  with  a  scale  factor  provides  a  davica-indapandant  means  of  generating  output 
at  a  Known  scale  factor.  In  metric  mode,  a  scale  factor  of  1 .0  indicates  that  tha  VSU  are  in  units  of 
millimetres;  a  scale  factor  of  0.0254  would  imply  VSU  of  one  thousarxi  par  irKh. 

Note  -  Tha  only  allowed  data  type  for  physical  device  units  is  integer.  Physical  devices  which 
support  real  number  physical  addessing  must  be  accessed  through  numeric  type  trarrsiation. 

5.5.9  DEVICE  VIEWPORT  MAPPING 

Parameters: 

Isotropy  flag  (one  of;  not  forced.  forced)(E) 

Horizontal  alignment  flag  (one  of;  Left.  Centre,  Right)(E) 

Vertical  alignment  flag  (one  of;  Bottom,  Centre,  Top)(E). 

Description: 

This  function  determines  how  the  coordirtate  mapping  is  derived  from  the  VDC  EXTENT  and  the 
specified  DEVICE  VIEWPORT.  See  the  DEVICE  VIEWPORT  description  for  a  fuller  explanation. 
The  remaining  parameters  are  only  significant  if  isotropy  is  forced  by  the  first  parameter.  If  so.  the 


SPECIRCATION  MODE 


(orw  of:  fraction  of  default  device  viewport 
milKnetres  wittt  sealefactor, 
physical  device  unite)(E) 

(R) 
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•ffactive  viawport  is  ganarally  smallar  than  tha  spacifiad  viawport,  and  thasa  paramatars  datarmma 
how  it  will  ba  positionad  within  tha  spacifiad  viawport.  'LafT  arxl  'bottom'  ara  intarpratad  as  baing 
towards  tha  first  cornar'  of  tha  spacifiad  DEVICE  VIEWPORT,  ragardlass  of  any  mirroring  or 
rotation  of  tha  viawport  on  tha  physical  davica. 


S.5.10  DEFERRAL  MODE 
Paramatars: 

dafarrai  moda  (orw  of:  asap.  bnig,  bnM,  asti)  (E) 

Dascriptlon: 

Dafarrai  mods  controls  tha  possibla  dalaying  of  output  functions:  for  axampla,  data  sant  to  a 
davica  may  ba  buffarad  to  optimizo  data  trarufar.  Tha  valuas  of  dafarrai  moda  (in  incraasing  ordar 
of  daisy)  ara: 

a)  ASAP:  Tha  visual  affact  of  aach  function  win  ba  achiavsd  As  Soon  As  Possibla  (ASAP). 

b)  BNI:  Tha  visual  affact  of  aach  function  wiH  ba  achiavad  Bafora  Nsxt  Intaraction  (BNI) 

d)  ASTI:  tha  visual  affact  of  attch  function  wiH  ba  achiavad  At  Soma  Tima  (ASTI). 

S^.11  MAKE  PICTURE  CURRENT 
Paramatars: 


Dascriptlon: 

This  function  ansuras  that  any  buffarad  data  is  sant  to  tha  davica's  display  surfaca,  such  that  it  Is 
visibla  to  tha  viawar. 


8.S.12  PREPARE  VIEW  SURFACE 
Paramatars: 

Foroa  hardcopy  advanoa  (orra  of:  forca  hardcopy,  conditionaO(E) 

Dascriptlon: 

This  function  discards  any  parnfing  data,  ciaars  tha  display  surfaca  of  a  softcopy  davica,  and 
daars  any  intamaliy>ator^  display  list.  Tha  claarad  ragion  is  sat  to  tha  colour  spacifiad  by 
BACKGROUND  COLOUR.  If  background  colour  is  supported. 

For  a  hardcopy  davica.  if  'forca  hardcopy  advance'  is  sat  to  'force  hardcopy',  tha  medium  is 
advanced  urwonditionaily.  If  tha  parameter  is  sat  to  'conditional',  tha  medium  is  not  advanced  if  it  is 
known  that  it  has  not  bean  marked;  if  tha  medium  is  marked,  or  if  tha  implamantation  cannot  tall 
whether  it  has  bean  marked,  than  tha  medium  is  advanced.  Tha  parameter  is  ignored  by  a  softcopy 
davica. 


5.5.13  UPDATE 
Paramatars: 

update  raganaration  flag  (one  of:  perform,  postpone)  (E) 

Description: 

This  alamant  indicates  that  all  dafarrad  actions  ara  executed  whan  tha  metafile  is  interpreted 
(without  intarmadiata  clearing  of  the  display  surfaca). 

5.5.14  MODIFY  FONT  LIST 
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Parameters: 


starting  index  (I) 
font  list  (S) 

Description: 

This  element  modifies  the  font  list  specified  in  the  FONT  LIST  element  or  the  default  list.  Only  the 
specified  entries  in  the  font  Kat  are  modified. 

Legal  values  of  the  starting  irxfex  are  non-negative  integers. 

5.5.15  MODIFY  CHARACTER  SET  LIST 

Parameters: 

starting  index  (I) 
list  of: 

character  set  type  -  one  of:  94-character  G-set, 

96-character  Q-set. 

94-character  multibyte  G-set, 

96-character  multibyte  G-set. 
complete  code)  (E). 

designation  sequerKe  tail  (S) 


Description: 

This  element  modifies  the  list  of  Character  Sets  given  in  the  Metafile  Descriptor  via  the 
CHARACTER  SET  LIST  element  or  the  default  list  Onit  the  specified  entries  are  modMed. 

5.5.16  BEGIN  FIGURE 
Parameters: 

none 

Descrfptfon: 

The  metafile  enters  the  sUte  'RGURE  OPEN  REGION  CLOSED',  initiating  construction  of  the 
compourvf  closed  figure  primitive. 

The  receipt  of  a  matching  END  RGURE  function  signals  the  rendering  of  the  closed  figure,  and  a 
transition  out  of  either  'FIGURE  OPEN  REGION  CLOSEC  or  'RGURE  OPEN  REGION  OPEN*  state 
back  to  'ACTIVE'. 

If  the  metafile  is  already  in  either  of  the  ’figure  open*  states,  the  previous  portion  of  the  closed 
figure  boundary  definition  is  discarded,  arxf  the  metafile  remains  in  the  ’figure  open’  state.  That  is. 
the  effect  is  as  if  the  boundary  definition  was  started  anew. 

5.5.17  END  FIGURE 
Parameters: 

none 

Description: 

This  furKtion  causes  transition  out  of  either  the  'RGURE  OPEN  REGION  OPEN  or  'FIGURE  OPEN 
REGION  CLOSED'  state,  and  causes  the  compound  closed  figure  primitive  to  be  rendered. 

If  the  metafile  was  in  state  'RGURE  OPEN  REGION  OPEN',  and  the  "last  point’  of  the  last  LINE 
function  is  not  coincident  with  the  current  closure  point,  then  the  closed  figure  has  not  been 
explicitly  closed  and  an  implicit  closure  is  performed  by  connecting  the  last  point  of  the  preceding 
LINE  function  to  the  current  closure  point.  The  visibility  of  this  line  segment  is  controlled  by 
IMPLICrr  EDGE  VISIBILfrf'. 

5.5.18  NEW  REGION 
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Param«t«rs: 


non* 

Description: 

This  function  is  used  only  within  th«  TIGURE  OPEN  REGION  OPEN*  stats,  for  control  of  subregion 
construction  within  closed  figures. 

If  the  current  region  has  not  yet  been  dosed  by  a  preceding  NEW  REGION  function,  and  the  last 
point  of  the  last  LINE  furKtion  is  not  coirKident  with  the  current  closure  point  then  the  current 
subregion  is  dosed  by  a  line  segment  conrtecting  the  last  point  of  the  preceding  LINE  function  to 
the  current  dosure  point.  If  the  region  has  been  previously  dosed  (i.e..  the  metafile  is  in  stats 
‘RGURE  OPEN  REGION  CLOSED’),  is  empty,  or  the  last  point  of  the  last  LINE  function  is 
coincident  with  the  current  dosure  point  then  no  line  segment  is  generated  by  this  function. 

The  visibiifty  of  this  line  segment  is  controlled  by  IMPLICIT  EDGE  VISIBILFTY. 

The  metafile  goes  to  the  state  'FIGURE  OPEN  REGION  CLOSED*.  The  first  point  of  the  next  LINE 
furrctlon  following  a  CLOSE  REGION  function  becomes  the  new  dosure  point  starting  a  new 
subregion. 

5.5.19  IMPLICIT  EDGE  VISIBILITY 
Paramatara: 

implldt  edge  visibility  (one  of:  off.on)(E) 

Description: 

IMPLICIT  EDGE  VISIBILfTY  specifies  whether  edges  added  hnplidtly  during  the  oonstruclion  of  a 
dosed  figure  are  to  be  rendered  as  visible  or  Invisible.  H  provides  control  for  each  edge,  that  is. 
each  knplidtiy  added  edge  obeys  the  current  value  of  IMPLICIT  EDGE  VISIBILITY. 

Edges  are  added  implidtiy  when  the  folowing  situations  arise  In  the  Hgure  open*  state: 

1 .  The  *first  point*  of  a  LINE  function  is  not  coincident  with  the  *1ast  point*  of  the  preceding  LINE 
function. 

2.  The  DISJOINT  POLYLINE  function  is  used. 

3.  A  NEW  REGION  function  is  irwoked,  the  metafile  is  in  state  'FIGURE  OPEN  REGION  OPEN*,  and 
the  *last  poinT  of  the  precedirrg  LINE  function  is  not  coincident  with  the  currerrt  dosure  point. 

4.  An  END  RGURE  furKtkm  is  invoked,  the  metafile  is  in  state  'RGURE  OPEN  REGION  OPEN*, 
arrd  the  last  poinr  of  the  preceding  LINE  function  is  not  coincident  with  the  current  dosure  pdnt. 

In  each  of  these  cases,  the  edge  connectmg  the  two  points  is  added  to  the  boundary  definition. 

This  function  may  be  used  anywhere  within  a  picture  (i.e..  both  before  and  during  the  dosed  figure 
definition);  however,  it  only  affects  the  reirdering  of  dosed  figures. 

5.5.20  SAVE  PRIMITIVE  ATTRIBUTES 
Parameters: 

Attrftjute  set  name  ASN 

Description: 

This  function  allows  the  generator  to  save  urxfer  the  given  name  a  copy  of  the  current  state  list 
entries  for  those  attributes  arxi  controls  listed  in  the  following  table. 

If  the  attribute  set  name  is  already  in  use,  the  values  saved  under  that  name  are  replaced  by  the 
current  values  and  no  error  is  generated. 
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TABLE  XX  Functtooa  wtrasa  stat«  list  enlriss  ar«  savsd  by  SAVE  PRIMITIVE  ATTRIBITTES  ■  jiorsd  by 
RESTORE  PRIMITIVE  ATTRIBl/TES 


AUXILIARY  COLOUR  (Note  1 ) 
ORAWMGMOOE 

transparb«:y 

LINE  BUNDLE  MDEX 
LINE  TYPE 
UNE  WIDTH  (Not*  2) 

LINE  COLOUR  (Notel) 

MARKB^  BUNDLE  INDEX 
MARKS?  TYPE 
MARKER  SIZE  (Not*  2) 
MARKS?  COLOUR  (Not*  1) 

FU.  BUNDLE  MDEX 
FU.  COLOUR  (Note  1) 

FILL  RS^ENCE  POINT 
WTB?IOR  STYLE 
HATCH  MDEX 

PATTH?N  WDEX 
PATTB?NSeE 


EDGE  BUNDLE  INDEX 
EDGE  TYPE 
EDGE  WIDTH  (Not*  2) 

EDGE  COLOUR  (Not*  1 ) 

EDGE  VISIBILITY 

IMPLICIT  EDGE  VISIBILITY 

CHARACTB?  SET  INDEX 
CHARACTER  EXPANSION  FACTOR 
CHARACTER  COOING  ANNOUNCER 
CHARACTER  SPACING 
CHARACTER  HEIGHT 
CHARACTER  ORIENTATION 
ALTB?NATE  CHARACTER  SET  INDEX 
TEXT  BUNDLE  MDEX 
TEXT  PRECISION 
TEXT  COLOUR  (Not*  1) 

TEXT  PATH 
TEXTALIG{«4Sfr 

ASPECT  SOURCE  FUGS 


CUP  RECTANGLE 
CUP  ff«>ICATOR 


Not*  1 :  Th*  COLOUR  SELECTION  MODE  in  which  this  vafci*  was  last  s*l  is  also  storad. 

Not*  2:  Th*  oorraspondng  spaeificatfon  mod*  in  which  this  valu*  was  last  sat  is  also  storad. 
S.5^1  RESTORE  PRIMITIVE  ATTRIBUTES 


Paramators: 

Attribut*  sat  nam*  ASN 


Dascriptlon 

Th*  valuas  savad  by  th*  last  SAVE  PRIMITIVE  ATTRIBUTES  using  Ih*  given  attribut*  set  name 
are  copied  into  th*  current  State  List  being  used  on  interpretation. 


5.5.22  DELETE  ATTRIBUTE  SET 
Parameters: 

Attribute  set  name  ASN 

Dascriptlon 

The  previously  saved  attribute  set  is  deleted  from  the  sets  stored. 
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Add  the  following  sub-clauses  after  sub-ciaus*  5.6.19 
5.6.20  CIRCULAR  ARC  CENTRE  BACKWARDS 
Parameters: 

centrepoint  (P) 
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DX  start.  DY  start.  OX  snd.  DY  and  (4VDC) 
radius  (VOC) 

Dascriptlon: 

A  drcutar  arc  is  drawn  which  is  dafinad  as  follows: 

DX_start  and  DY_start  dafirw  a  start  vactor.  and  DX_end  and  DY_and  dafina  an  and  vactor.  The 
tails  of  thasa  vectors  are  placed  on  the  cantrapoint  A  start  ray  aixf  and  ray  are  darivad  from  the 
start  and  and  vactors.  Tha  start  arvi  and  rays  ara  sami-infinita  llnas  from  tha  cantrapoint  in  the 
diractiora  of  tha  start  and  end  vactors  raspar^aly. 

Tha  spacifiad  radius  artd  cantrapoint  dafina  a  cirda.  Tha  arc  is  drawn  in  tha  negative  angular 
direction  (as  dafirtad  by  VOC  EXT^T)  from  tha  intersection  of  the  drda  and  tha  start  ray  (as 
obtained  by  measuring  a  distance  Yadius*  along  tha  start  ray  from  tha  cantrapoint)  to  tha 
intersection  of  tha  drda  and  tha  and  ray. 

Tha  arc  is  displayed  with  currant  line  alamant  attributes. 

Valid  vaiuas  of  tha  vactor  comporrants  ara  those  which  prixfuca  vactors  of  noivzaro  length. 

Valid  vaiuas  of  'radius  ara  rK>r>-r)agaiiva  VOC. 

if  tha  start  ray  arxf  and  ray  ara  coinddant.  it  is  ambiguous  whether  tha  dafinad  arc  subtends  0 
degrees  or  360  degrees  of  central  angle  (sea  also  annex  0). 

5.6.21  PIXEL  ARRAY 
Parameters: 


origin  point 

(P) 

nx/ry 

(21) 

vafidx  range 

(21) 

vaidy  range 

(21) 

xacala 

(«) 

yacaia 

(1) 

colour  spadliars 

(nx*ny  CO) 

Description: 

Assigns  a  row  major  racta^ular  array  of  device  independent  colour  spacifiars  to  a  rectangular 
array  of  pixels,  nx  and  ny  dimension  the  rectangular  array  of  device  ir>dapandant  colour  spacifiars. 
(Hare  arid  aisawhara  in  ^is  discussion  wa  ara  rafaring  to  tha  absoiuta  value  of  nx  and  ny  since  tha 
signs  of  these  vaiuas  (sea  below)  ara  used  to  irxficata  tha  directions  in  which  succeeding  pixels  ara 
drawn.) 

Tha  origin  is  tha  location  in  VOC  space  of  tha  drawing  bitmap  at  wWch  tha  first  colour  value  is  to  be 
placed. 

nx  is  a  signed  integer,  the  absoiuta  value  of  which  defines  how  many  pixels  ara  In  each  row.  If 
nx>0,  than  tha  row  extends  toward  increasing  VDC  X  from  tha  origin  point.  If  nx<0.  than  the  row 
extends  toward  decreasing  VDC  X  from  tha  origin  point 

ny  is  a  signed  integer,  tha  absolute  value  of  which  defines  how  many  rows  of  pixels  there  are.  tf 
ny>0.  than  each  new  row  is  toward  increasing  VDC  Y.  If  ny<0.  than  each  new  row  Is  toward 
dacraasing  VDC  Y. 

valid  X  range  and  valid  y  range  specify  the  subrectangla  within  the  array  which  is  to  be  drawn  into 
tha  bitmap  (refer  to  figure  6).  This  allows  a  rectangular  subregion  of  tha  pixel  array  to  be  rendered. 
If  tha  valid  x  or  y  rar^a  extends  beyond  tha  limits  of  tha  nx  by  ny  array  of  colour  specifiers,  then 
tha  valid  x  or  y  range  is  "clipped*  to  tha  nx  by  ny  limits  of  the  array,  with  only  those  values  in  the 
valid  X  arxf  y  ranges  which  ara  also  in  tha  limits  of  the  colour  specifier  array  being  rardered. 

X  scale  and  y  scale  permit  integer  scaling  of  tha  pixel  array  rendering  irxlapendantly  in  the  x  and  y 
dimensions  (sea  figure  6).  Thasa  scale  factors  must  be  positive  integers. 

If  nx  or  ny  or  X  scale  or  y  scale  -  0,  nothing  is  drawn. 
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Add  the  following  sub-clausos  attar  sub-ciauaa  5.7.35 


5.7.36  LINE  REPRESENTATION 
Paramatars: 

Hna  but>dla  indax  (IX) 

Hna  typa  indicator  (IX) 

Hna  width  apactfiar,  aithar 

abaohita  Hna  width  (VOC) 
or 

Hna  width  scala  factor  (R) 
Hna  colour  spacifiar.  aithar 

Hthi  colour  Indax  (Cl) 
or 

Hna  colour  vaiua  (CO) 


Daaerlptlon: 

In  tha  Hrw  tiundla  tabia,  tha  givan  Hria  bundia  Indax  la  assodatad  with  tha  spacilie  paramatars. 

Una  typa  is  spaefflad  and  bahavas  as  inefleatod  in  tha  LINE  TYPE  attrfbuta  function. 

Lina  width  b  dafinad  In  tha  currant  UNE  WIDTH  SPECIFICATION  MODE  and  is  storad  in  tha  bunda 
tabia  along  with  that  moda.  Thus,  tha  dattnition  is  immuna  to  subsaquant  changas  to  tha  salaction 
ffloda. 

Tha  Hna  bundia  tabb  has  prsdafinad  antiias.  Each  antry  rsndars  a  dbiinet  appaaranca  from  othar 
pradafirwd  antriaa.  Any  tabia  antry  (including  tha  pradafinad  antrias)  may  ba  radafinad  with  this 
function.  Radattning  a  tabb  antry  or  adding  a  naw  tabb  antry  may  aHminata  tha  ability  to  randar  a 
distinct  appaaranca  from  othar  tabb  antrias. 

Whan  Hna  functions  ara  dbpbyad  tha  lina  bundia  indax  rafars  to  an  antry  in  tha  lina  burdb  tabb. 

WWch  aspacts  in  tha  antry  ara  usad  daparxts  upon  tha  satting  of  tha  oorraspondmg  ASFs,  saa  tha 
ASPECT  SOURCE  FIAGS  function. 


5.7.37  MARKER  REPRESENTATION 
Paramatars: 


marHar  bundia  irtoax  (IX) 
markar  typa  indicator  (IX) 
markar  siza  spacifiar.  aithar 

absoluta  markar  siza  (VDC) 
or 

markar  siza  scala  factor  (R) 
markar  colour  spacifbr.  aithar 

markar  colour  indax  (Cl) 
or 

marker  colour  value  (CO) 


Description: 

In  tha  markar  bundia  table,  tha  given  markar  bundia  indax  is  associated  with  tha  specified 
parameters. 

Marker  type  is  specified  and  behaves  as  indicated  in  the  MARKER  TYPE  attribute  function. 
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Marker  size  is  defined  in  the  cun’ent  MARKER  SIZE  SPECIFICATION  MODE  and  is  stored  in  the 
bundle  table  along  with  that  mode.  Thus,  the  definition  is  immurw  to  subsequent  changes  to  the 
specification  mode. 

Marker  colour  is  defined  in  the  current  COLOUR  SELECTION  MODE,  and  Is  stored  in  the  bundle 
table  along  with  that  mode.  Thus  the  definition  is  immune  to  subsequent  changes  to  the  selection 
mode. 

The  marker  bundle  table  has  predefir>ed  entries.  Each  entry  renders  a  distinct  appearar>cs  from 
other  predefined  entries.  Any  table  entry  (mciuding  the  predefined  entries)  may  be  redefined  with 
this  function.  Redefining  a  table  entry  or  adding  a  new  table  entry  may  eliminate  the  ability  to 
rerxlar  a  distinct  appeararKs  from  other  table  entries. 

When  polymarkers  are  displayed  the  marker  bundle  index  refers  to  an  entry  in  the  marker  bundle 
table. 

Which  aspects  in  the  entry  are  used  deperxfs  upon  the  setting  of  the  corresponding  ASFs.  see  the 
ASPECT  SOURCE  FLAGS  function. 


S.7.38  TEXT  REPRESENTATION 
Parameters: 

text  burxlle  index  (IX) 
text  font  index  (IX) 

text  precision  (one  of:  string,  character,  stroke)  (E) 
character  expansion  factor  (R) 
character  spacing  (R) 
text  colour  specifier,  either 

text  colour  irxiex  (Cl) 
or 

text  colour  value  (CO) 

Description: 

In  the  text  burKNe  table,  the  given  text  bundle  index  is  associated  with  the  specified  parameters. 

Text  font  index  is  specified  and  behaves  as  indcated  in  the  TEXT  FONT  INDEX  attribute  function. 

Text  precision  is  specified  arxi  behaves  as  irxficated  in  the  TEXT  PRECISION  atbibute  function. 

Character  expansion  factor  is  specified  arxl  behaves  as  indicatsd  in  the  CHARACTER  EXPANSION 
FACTOR  attribute  function. 

Character  spacing  is  specified  and  behaves  os  indicated  in  the  CHARACTER  SPACING  attribute 
function. 

T  ext  colour  is  defirwd  in  the  current  COLOUR  SELECTION  MODE,  and  is  stored  in  the  bundle  table 
along  with  that  mode.  Thus,  the  definition  is  immune  to  subsequent  changes  to  the  selection 
mode. 

The  text  bundle  table  has  predefined  entries.  Each  entry  renders  a  distinct  appeararKe  from  other 
predefined  entries.  Any  table  entry  (including  the  predefined  entries)  may  be  redefined  with  this 
function.  Redefining  a  table  entry  or  adding  a  new  table  entry  may  eliminate  the  ability  to  rerxfer  a 
distinct  appearance  from  other  table  entries. 

When  text  is  displayed  the  text  bundle  index  refers  to  an  entry  in  the  text  bundle  table. 

Which  aspects  in  the  entry  are  used  deperxls  upon  the  setting  of  the  correspondir^  ASFs,  see  the 
ASPECT  SOURCE  FLAGS  function. 


5.7.39  FILL  REPRESENTATION 
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Partmctars: 


fill  ar«a  bundl*  indax  (IX) 

intarior  styla  (ona  of:  hollow,  solid,  pattam.hatch,  amptyXE) 
fl  colour  spaciflar,  althar 

fin  colour  indax  (Cl) 

Of 

fill  colour  vahia  (CO) 
hatch  Max  (IX) 
pattam  Max  (IX) 


Oaaerlptlon: 

in  tha  fill  bundia  tabla,  tha  givan  fill  bundto  indax  is  aaaodatad  with  tha  spacifiad  paramaiars. 

Intarlor  styla  is  spadBad  and  bahavaa  as  Micatad  in  lha  INTERIOR  STYLE  attributa  function. 

Hatch  Max  Micator  Is  spaciflad  and  bahavas  as  indicatsd  in  tha  HATCH  INDEX  attributa  function. 

Pattam  indax  indicator  is  spacifiad  and  bahavas  as  indicatsd  in  tha  PATTERN  INDEX  attributa 
function. 

Fill  colour  is  dafinad  In  tha  currant  COLOUR  SB.ECT10N  MODE,  and  is  storad  in  tha  bundia  tabla 
along  with  that  moda.  Thus,  tha  dafinition  is  immuna  to  subsaquant  changas  to  tha  salaction 
moda. 

Tha  flB  burxfls  tabla  has  pradafinad  antriaa.  Each  anfry  randars  a  disfinct  appaaratrca  from  othar 
pradafinad  antriaa.  Any  tabla  antry  (Mluding  pradafinad  antifaa)  may  ba  radaflnad  with  this 
function.  Radafining  a  tabla  antry  or  addirtg  a  naw  tabla  antry  may  aflmlnata  fha  abBIty  to  rarxfar  a 
distinct  appaarartoa  from  othar  tabla  antrias. 

Whan  fin  araaa  ara  cfispiayod  tha  fill  burKla  Max  rafars  to  an  antry  In  tha  fin  bundia  tabla. 

Which  aspacts  In  tha  antry  ara  usad  dapands  upon  tha  satting  of  tha  corrasponding  ASFs,  saa  tha 
ASPECT  SOURCE  FLAGS  function. 


S.7.40  EDGE  REPRESENTATION 
Paramatars: 

adga  bundia  Max  (IX) 
adga  typa  Micator  (IX) 
adga  width  spacifiar.  aithar 

abs^a  adga  width  (VOC) 
or 

adga  width  seals  factor  (R) 
adga  colour  spacifiar,  aithar 

adga  odour  Max  (Ci) 
or 

adga  odour  valua  (CD) 

Dascriptlon: 

in  tha  adga  burKfia  tabla,  tha  givan  adga  bundia  Max  is  assodatad  with  tha  spacifiad  parameters. 

Edge  typa  is  spacifiad  and  behaves  as  indicated  in  the  EDGE  TYPE  attribute  furvttion. 

Edge  width  is  defined  in  the  current  EDGE  WIDTH  SPECIFICATION  MODE  aryl  is  stored  in  the 
bundia  tabla  along  with  that  moda.  Thus,  the  definition  is  immune  to  subsequent  changes  to  the 
specification  mode. 

Edge  colour  is  defirred  in  the  current  COLOUR  SELECTION  MODE  and  is  stored  in  the  bundle  table 
along  with  that  mode.  Thus,  the  derinition  is  immune  to  subsequent  changes  to  the  selection 
mode. 
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Th«  adg*  bundle  table  has  predefined  entries.  Each  entry  renders  a  distirtet  appeararKS  from  other 
predefined  entries.  Any  table  entry  (including  predefined  entries)  may  be  redefined  with  this 
function.  Redefining  a  table  entry  or  addir>g  a  new  table  entry  may  eliminate  the  ability  to  render  a 
dbtinct  appearance  from  other  table  entries. 

When  ffll  areas  are  displayed  the  edge  bundle  index  refers  to  an  entry  in  the  edge  bundle  table. 

WNch  aspects  in  the  entry  are  used  deperxfs  upon  the  setting  of  the  corresponding  ASFs,  see  the 
ASPECT  SOURCE  FLAGS  function. 

5.7.41  PICK  IDENTIFIER 
Parameters: 

pick  identifier  (I) 

Description: 

The  pick  identifier  is  associated  with  all  of  the  graphical  primitive  elements  of  a  segment  until  the 
next  PICK  lOENTIRER  element 

WHh  pick  input  a  structure  is  returned  consisting  of  the  picked  segment  identifier  and  a  pick 
identifiar.  pick  identifier  represents  the  grapNcai  elements  that  were  associated  with  H  during 
creation  of  the  segment  This  pick  structure  is  returned  only  if  the  picked  segment  is  both  VISIBLE 
and  DETECTABLE.  The  default  pick  identifier  is  zero. 

5.7.42  DRAWING  MODE 

Parameters: 

Gawfingmode  (I) 

Description: 

Drawing  mode  is  an  Integer  in  the  range  [0..15]  which  defines  the  logical 
operatic  between  the  source  and  destination  during  al  output  operations. 

TABLE  XX.  Drawing  modes 


The  16  possible  combinations  are  defined  as  foiiows 
(d*  <■  resulting  destination  bit  value, 
d  m  originai  destination  bit  value, 
s  m  origirtal  source  bit  value); 


Drawing  Mode 


Logical  Operation 


0 

1 

2 

3 

4 

5 

6 

7 

8 

9 

10 
11 
12 

13 

14 

15 


<SmO 

d.sANDd 
(f  -  SAND  (NOT  d) 
(f  -  s 

d* .  (NOT  s)  AND  d 
d-d 

d  -  s  XOR  d 
d  -  s  OR  d 
d-NOT(sORd) 
d  -  NOT  (s  XOR  d) 
d-NOTd 
d  -  s  OR  (NOT  d) 
d-NOTs 
d-(NOT3)  ORd 
d-NOT(9  AND  d) 
d-1 
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Add  th«  fonowing  sub-dauM  after  sub-clause  5.9: 

5.10  Segment  Elements 

5.10.1  REOPEN  SEGMENT 
Parameters: 

segment  identifier  (SN) 

Description: 

The  segment  corresporxling  to  the  specified  identifier  is  reopened.  Subsequent  graphical  objects 
are  appended  to  the  segment. 

Issuing  a  REOPEN  SEGMENT  with  an  identifier  which  is  not  currently  in  use  is  an  error  aixf  the 
function  is  ignored. 

The  display  of  graphical  objects  which  are  added  to  an  existing  segment  deperrds  on  the  segment 
visibility,  the  segment  Nghlighting,  the  impicit  segment  regeneration  mode,  and  the  segment 
display  priority. 

5.10.2  COPY  SEGMENT 
Parameters: 

segment  idenllfier  (SN) 

copy  transformation  matrix: 

scalirrg  and  rotation  portion  2x2xR 

trarwiation  portion  2x1xVDC 


Description: 

All  graphicai  objects  in  the  identified  segment  are  reentered  into  the  pipeline  and  placed  Into  the 
open  segment  The  Identified  segment  Is  referred  to  as  the  copM  segment  The  segment 
attributes  of  the  copied  segment  are  ignored.  The  segment  atbibutes  of  the  open  segment  are 
unchanged  by  the  COPY  STOMENT  function. 

The  copy  trarrsformation  is  applied  to  all  graphicai  objects  of  the  copied  segment  before  they  are 
copied  into  the  open  segment  The  copy  trarrsformation  is  not  appiied  to  clipping  rectangles. 

The  COPY  SEGMENT  furrction  duplicates  ail  of  the  grapNcal  objects  of  the  copied  segment  as 
though  the  client  had  invoked  CGI  furxrtions  to  define  the  objects  as  transformed. 

The  display  of  graphical  objects  which  are  copied  into  the  open  segment  depends  on  the  segment 
visibility,  the  segment  highlighting,  the  implicit  segment  regeneration  mode,  and  the  segment 
display  priority. 

The  INHERITANCE  RLTER  function  allows  for  control  of  the  attribute  values  wNch  are  used  when 
copying  segments.  This  filter  controls  whether  individual  attribute  values  are  reapplied  to  the 
graphicai  objects. 


5.10.3  DELETE  SEGMENT 
Peremeters: 

segment  identifier  (SN] 

Description: 

The  identified  segment  is  deleted. 

NOTE  -  The  segment  identifier  may  appear  in  a  subsequent  BEGIN  SEGMENT  element. 
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5.10.4  DELETE  ALL  SEGMENTS 


ParamcUra: 


Description: 

All  segments  are  deleted  from  segment  storage.  All  segment  identifiers  may  be  reused  by  the 
BEGIN  SEGMENT. 

Display  ehairges  resulting  from  the  deletion  of  ell  segments  are  governed  by  the  implicit  segment 
regeneration  mode  and  dynamic  modification  accepted  for  segment  deletion. 

If  the  description  table  entry  *Oynamlc  modification  accepted  for  Segment  Deletion*  is  set  to  IMM, 
the  effect  of  DELETE  ALL  SEGMPfTS  happens  immediately.  If  the  dynamic  modification  entry  is 
set  to  IRG,  the  effect  of  DELETE  ALL  SEGMENTS  depends  on  the  setting  of  the  *Impficit  Segment 
Regeneration  Mods*  entry  in  the  state  list,  as  follows: 

if  the  ImpMcIt  segment  ragenaration  mode  la  ALLOWED,  any  image  modMeation  neoassary  as  a 
result  of  the  DELETE  ALL  SEGMENTS  function  will  be  achieved  by  an  immediate  implicit 
ragenaration. 

If  the  ImpUcit  segment  ragerteration  mode  is  SUPPRESSED,  any  Image  modMeation  necessary  as 
a  result  of  the  DELETE  ALL  SEGMENTS  function  will  not  take  place  until  some  expidt  action  is 
performed. 


5.10.5  RENAME  SEGMENT 

Parameters: 

old  segment  kienll  War  (SN) 
new  segment  Identlllar  (Sf^ 

Description: 

An  existing  segment  is  associated  with  a  new  segment  Identifier. 


5.10.6  REDRAW  ALL  SEGMENTS 
Parameters: 


Description: 

This  function  is  intended  to  result  in  a  redraw  of  ail  defined  segments.  However,  if  a  segment's 
visibility  attribute  is  INVISIBLE,  that  segment  is  not  drawn.  Segments  of  higher  display  priority 
should  always  appear  to  cover  overlapping  segments  of  lower  display  priority. 


5.10.7  IMPUCIT  SEGMENT  REGENERATION  MODE 
Parameters: 

implicit  segment  regeneration  mode  (one  of:  SUPPRESSED.  ALLOWED)(E) 

Description: 

The  implicit  segment  rsgerwration  mode  for  picture  changes  is  set  to  SUPPRESSED  or  ALLOWED. 
The  IMPUCIT  SEGMENT  REGENERATION  MODE  function  may  be  issued  at  any  time. 

If  the  mode  is  ALLOWED  then  the  interpreter  may  perform  an  implicit  PREPARE  VIEW  SURFACE 
and  REDRAW  ALL  SEGMENTS  depernfing  on  the  dynamic  modification  accepted  values.  In  this 
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mod*,  an  op*n  segment  (or  any  other  segment)  may  be  redrawn  whenever  changes  aftect  the 
appearance  of  the  view  surface.  In  such  cases,  all  non-retained  data  are  lost 

When  set  to  SUPPRESSED,  the  interpreter  must  explicitly  invoke  PREPARE  VIEW  SURFACE  and 
REDRAW  ALL  SEGMENTS  or  REDRAW  SEGMENT  to  re^aw  graphical  objects  stored  in  segmerrts. 
H  a  segment  is  open,  it  must  be  dosed  (END  SEGMENT)  prior  to  invokir^  explicit  segment  display 
functions. 

Soma  devices  cannot  immediately  chartge  a  picture.  A  plotter  for  example  can  only  add  to  a 
picture.  It  would  need  to  advance  the  paper  arKl  redraw  the  picture  to  show  the  effect  of  a 
transformation  change.  Changes  in  display  priority  could  cause  different  sectiora  of  a  picture  to 
become  visibl*  or  obscured.  Visibility  arid  higNighting  may  also  cause  the  picture  to  change. 

On  devices  where  pictures  are  addtiv*  only  (i.e.,  cannot  eras*  or  change  part  of  a  picture)  implicit 
segment  regeneration  mod*  of  SUPPRESSED  is  more  efficient  in  terms  of  Urn*  and  material. 
Iffl^idt  segment  regeneration  mod*  gives  the  client  the  ability  to  accumulate  picture  changes.  At 
some  later  time,  the  dient  can  explicitly  utiUz*  PREPARE  VIEW  SURFACE  and  REDRAW  ALL 
SEGMENTS. 

The  default  IMPLICIT  SEGMENT  REGENERATION  MODE  is  SUPPRESSOR. 

5.1 0.8  INHERITANCE  FILTER 
Parameters: 

fSter  seiectkxi  attribute  designator  (list  of: 

(IndMdual  function  names), 

(Ss*  below) 

LtCATTRBUTES, 

MARKER  ATTRBUTES, 

TEXTATIRBUTES, 

CHARACTHR  ATTRIBUTES 
IRLL  ATTRBUTES, 

EDGE  ATTRBUTES, 

PATTBTNATTRBUTES. 

CUP  CONTROL 
OUTPUT  CONTROL 
AaXnE) 

setting  (STATE_USrr.SEGMENT)(E) 

Description: 

The  setting  of  the  inheritance  filter  is  modified  for  those  attributes  in  the  filter  selection  list. 
According  to  the  setting,  attributes  are  inherited  from  the  current  state  lists  or  from  the  copied 
segment. 

The  individual  function  names  permitted  are  those  listed  in  Table  XX,  'Inheritance  Filter  Function 
Groups',  as  one  of  the  attributes  included. 

It  an  attribute  or  group  of  attributes  designated  in  the  filter  selection  list  is  set  to  STATE_LiST, 
graphical  objects  inherit  that  attribute  or  group  of  attributes  from  the  current  state  lists  when  a 
segment  is  copied. 

If  an  attribute  or  group  of  attributes  designated  in  the  finer  selection  list  is  set  to  SEGMENT,  that 
attribute  or  group  of  attributes  is  unaffected  (in  all  graphical  objects  employing  them)  by  the 
corresponding  CGI  state  list  when  a  segment  is  copied. 

The  default  inheritarKe  filter  setting  value  is  SEGMENT  for  all  attributes. 

The  groups  of  attributes  are  defined  in  the  table  below. 

TABLE  XX  Inheritance  Filter  Function  Groups 


Attribute  Group  Attributes  Induded 
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UNEATmeUTES 


MARKER  ATTRBinES 


TEXTATTRBLrrES 


CHARACTER  ATTRBUTES 


FILATTRBUTES 


BDGEATTRBLrTES 


PATTERN  ATTRBLrTES 
CUP  CONTROL 
OITTPUT  CONTROL 

ALL 


UNE  BUNDLE  INDEX 

LINE  TYPE 

UNE  WIDTH 

U?«  COLOUR 

MARKER  BUNDLE  MDEX 

MARKER  TYPE 

MARKER  SIZE 

MARKER  COLOUR 

TEXT  BUNDLE  MDEX 

TEXT  FONT  NDEX 

TEXT  PRECISION 

CHARACTER  EXPANSION  FACTOR 

CHARACTER  SPACING 

TEXT  COLOUR 

CHARACTER  HEIGHT 

CHARACTER  ORIBTTATION 

TEXT  PATH 

TEXTALIGNMBfr 

CHARACTB)  SET  NDEX 

ALTBVIATE  CHARACTER  SET  INDEX 

FILL  BUNDLE  INDEX 

INTB^IOR  STYLE 

FU.  COLOUR 

HATCH  NDEX 

PATTERN  NOEX 

aXSE  BUNDLE  IMDEX 

BX3ETYPE 

BX3E  WIDTH 

BX3E  COLOUR 

EDGE  VISIBILITY 

FLL  RBERBICE  POINT 

PATTERN  SIZE 

CUP  RECTANGLE 

CUP  INDICATOR 

AUXIJARY  COLOUR 

TRANSPAR04CY 

DRAWING  MODE 

All  attributes  controllad 


5.10.9  SEGMENT  TRANSFORM 
Paramatars: 


sagmant  idantifiar  (SN) 
transtormation  matrix  (4R  2VDC) 


Daaerlptlon: 

Tha  matrix  is  stored  in  lha  idantiflad  sagmant  as  a  sagmant  attribute.  The  sagmant  transform 
raplacas  the  old  sagmant  transform.  Thera  is  no  accumulation  of  matrices. 

Whan  a  sagmant  is  displayed,  tha  sagmant  transform  is  applied  to  all  rafaranca  points  in  VDC 
space  with  tha  following  matrix 

|X’l  |M11  M12  M13|  |X| 

I  I  -  I  I  *  |Y| 

|Y1  |M21  M22  M23|  |1| 

where  X  an  Y  is  tha  original  coordinate  pair  and  X  and  Y’  is  tha  new  coordinate  pair. 

Rafaranca  points  may  refer  to  both  output  primitive  coordinate  pairs  as  wall  as  to  geometric 
attributes.  Note  that  tha  rafaranca  points  for  all  output  primitives  are  defined  to  be  input 
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paramvters  of  type  POINT.  In  the  case  of  reference  points  for  geometric  attributes  that  are  of 
vectors,  such  as  CHARACTER  ORIENTATION,  the  translation  portion  of  the  matrix  Ml 3  and  M23 
is  not  applied. 

The  default  segment  transform  is  the  identity  matrix.  The  segment  transform  may  be  set  after  a 
segment  has  been  open  or  created.  It  is  permissible  to  change  the  transform  of  the  open  segment 


5.10.10  SEGMENT  VISIBILITY 
Parameters: 

segmerrt  identifier  (SN) 

visibility  (one  of:  visible,  invisible)  (E) 

Description: 

When  the  visibility  attribute  Is  set  to  Visibie*.  the  segment  may  be  displayed.  When  this  attribute  is 
set  to  Invisible'  the  segment  must  not  be  displayed. 

NOTE  •  Invisible  segments  cannot  be  picked. 


5.10.11  SEGMENT  HIGHLIGHTING 
Parameters: 

segment  identifier  (SN) 

highlighting  (one  of:  normal.  higNIghtod)  (E) 

Description: 

When  the  highlighting  attribute  is  set  to  'highiighted'.  the  visual  appearance  of  the  segment  is 
implementation  deperKient  When  the  higNighting  attribute  b  set  to  'normaT,  the  segment  is 
di^ayed  according  to  the  segment  artd  primitive  attributes. 


5.10.12  SEGMENT  DISPLAY  PRIORITY 
Parameters: 

segment  identifier  (SN) 

segment  display  priority  (I) 

Description: 

The  segment  display  priority  for  the  identified  segment  is  set  to  the  specified  value. 

Segments  with  higher  segment  display  priority  appear  to  be  in  front  of  s^ments  with  lower  segment 
display  priorities.  When  the  segment  display  priorities  of  two  overlapping  segments  are  the  same, 
the  order  in  which  they  appear  is  implementation  deperrdent. 


5.10.13  SEGMENT  DETECTABILITY 
Parameters: 

segment  identifier  (SN) 

detectability  (one  of:  detectable,  urrdetectable)  (E) 

Description: 

When  the  detectability  attribute  is  set  to  'detectable'  and  the  visibility  attribute  to  'visible',  the 
segment  can  be  picked,  'detectable'  but  'invisible'  or  'undetectable'  segments  cannot  be  picked. 
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5.10.14  SEGMENT  PICK  PRIORITY 


Paramstors: 


sagmant  idantifiar  (SN) 

sagmant  pick  priority  (I) 

Daserlptlon: 

Tha  sagmant  pick  priority  for  tha  idantifiad  sagmant  Is  sat  to  tha  spadfiad  vakja. 

This  valua  is  usad  to  datarmirw  which  sagmant  b  to  ba  pickad  whan  sagmants  ovariap.  Tha 
sagmant  with  tha  highast  pick  priority  b  pickKt  first 


Pag*  103 

Clausa  6:  Add  tha  fallowing  at  tha  and  of  dausa  6: 


METAFILE  CATEGORY 
MAXMUM  VDC  EXTENT 

SEGMBTT  PRIORITY  EXTeiT 
DEVICE  VIEWPORT 

DEVICE  VIEWPORT  SPECIFICATION  MODE 
DEVICE  VIEWPORT  MAPPING 
DB^ERRALMODE 
UPDATE 

IMPLICfT  EDGE  VISIBILRY 
LINE  RB>RESBITAT10N 
MARKER  REP 
TEXT  REPRESENTATION 
FILL  REPRESENTATION 
EDGE  REPRESENTATION 
PICK  IDBfHRER 
DRAWING  MODE 

IMPLICIT  SEGMENT  REGENERATION  MODE 
INHERITANCE  FILTER 
SEGMBVT  TRANSFORM 

SEGMENT  VISIBILITY 
SEGMENT  HIGHLIGHHNG 
SEGMENT  DISPLAY  PRIORITY 


boaieegm 

042787  for  VDC  typa  intagar 
0.0.1.0  for  VDC  ty^  raol 

0-7 

l.d. 

fraeliom  of  dbptay  suifaea 
forcadjaftbottom 

asap 


off 

i.d. 

l.d. 

i.d. 

i.d. 

i.d. 

n/a 

afrY-s) 

supprassad 

sagmant 

1.0.0 

0.1.0 

visibla 

normal 

0 
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SEGMBIT  DETECTABILrTY 
SB3MBIT  PICK  PRIORITY 


undetectable 


0 
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Add  the  following  clause  after  clause  7.4 

7.5  Conformance  by  Mataflia  Catagory 

A  metafile  must  conform  to  the  metafile  category  defined  in  the  Metafile  Descriptor.  Thia  conformarwe  is  to 
the  abstract  specification  artd  erKodings  in  the  way  described  above.  Conformance  to  a  metafile  category 
occurs  when  the  metafile  also  conforms  to  the  formal  grammar  for  that  category. 

Paga127 

Add  the  foUowing  text  to  the  end  of  clause  D4.4 
SCALING  MODE  and  DEVICE  VIEWPORT 

If  both  devioa  viewport  and  sealktg  mode  appear  in  the  same  metafile  then  the  last  specified  is  used.  K 
neither  appear  then  the  default  values  for  device  viewport  take  precedence  where  these  are  allowed  in  the 
same  category. 

Pag*  132 

Add  the  foHowirtg  clause  after  clause  D.4.8 

D.4.9  Segment  Elements 

If  there  is  an  attempt  to  open  a  segment  which  exists  then  the  OPEN  is  igrK>red. 


Pag*  144 

Add  the  following  clauses  after  sub-clause  E.6 
E.7  QKS  Item  Types 
<This  wifl  be  the  list  from  Annex  E  of  GKS> 

E.8  The  Relationship  of  Fonts  Between  CGM  and  GKS 

The  GKS  standard  irrcludes  the  concepts  of  text  output  primitive  attributes.  However,  the  mechanism  for 
specifying  the  text  font  differs  from  that  specified  in  the  CGM  stondard.  This  clause  suggests  an  approach 
to  handling  these  attributes  within  the  GKS  environment  when  the  CGM  is  used  as  a  GKS  Metafile. 

E.8.1  Overview  of  the  Differences  Between  GKS  and  CGM  Fonts 

WNIe  CGM  supports  the  TEXT  output  primitive  attribute  functionaility  of  GKS,  a  one-to-one  mapping 
between  CGM  and  GKS  is  not  possible  in  all  cases.  Specifically: 

1 .  GKS  and  CGM  differ  in  the  way  fonts  are  delirwd: 

In  the  CGM  text  fonts  are  defined  with  the  FONT  ILIST  element  that  associates  font  names  or 
identifications  with  entries  in  a  Font  Table.  The  Font  Table  can  be  modified  with  the  MODIFY  FONT 
LIST  element 

In  GKS.  no  mechanism  is  available  for  defining  text  fonts.  GKS  associates  a  unique  text  font 
number  with  each  font.  The  Registration  Authority  is  responsible  for  defining  this  mapping  of  font 
numbers  to  specific  font  identifications. 
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2.  GKS  and  CGM  diffar  in  tha  way  fonts  ara  safactad 

In  tha  CGM,  taxt  fonts  ara  salactad  with  tha  TEXT  FOI^  INDEX  alamant  Tha  indax  salacts  an 
indaividuai  font  from  diffarant  fonts  in  tha  font  list. 

In  GKS,  taxt  fonts  ara  salactad  with  a  font  numbar.  Tha  font  numbar  salacts  a  spactfic  GKS 
ragistarad  font  if  tha  vaiua  is  positiva.  If  tha  font  numbar  is  nagativa  an  implamantation  dapandant 
font  is  salactad. 

3.  GKS  and  CGM  diffar  on  tha  indapandanca  of  font  and  taxt  pracision 

In  tha  CGM,  tha  font  and  taxt  pracision  ara  spacifiad  by  ifKtapandant  alamants. 

In  GKS,  tha  font  and  taxt  pracision  ara  diractiy  assodatad  with  spadfication  by  a  singia  function. 

4.  GKS  and  CGM  dHfar  in  charadar  oriantation  capability 

In  CGM,  tha  charactar  oriantation  is  spadfiad  by  both  a  Charactar  Up  Vactor  arxf  a  Charactar  Basa 
Vactor.  Skawad  spadficationa  ara  possibia. 

In  GKS,  tha  charactar  oriantation  is  spadfiad  by  a  Charactar  Up  Vactor.  Tha  Charactar  Basa 
Vactor  is  always  aqual  to  positiva  90  dagraas  from  tha  Charactar  Up  Vactor.  Skawad  spadfication 
is  not  possibla. 

5.  Soma  CGM  Bamants  hava  no  oountarpart  as  GKS  functions 

Thasa  induda:  charactar  sat  ralatad  aiamants,  such  as  CHARACTER  SET  LIST,  CHARACTER 
COOING  ANNOUNCBl,  CHARACTB^  SET  INDEX.  ALTERNATE  CHARACTER  SET  INDEX;  and 
Auxilary  Colour  ralatad  alamants,  such  as  AUXILUARY  COLOUR  and  TRANSPARENCY  that 
affact  tha  prasarttatton  of  taxt 

This  additional  functionality  of  tha  CGM  eausas  rw  spadal  problams  for  a  GKS  anvironmant 
intarprating  a  CGM  of  eatagory  GKSM  sinos  tha  catagory  rastricts  tha  oocurranoa  of  tha  alamants 
assodatad  with  thb  additional  functiondity.  Thus,  tha  intarpratation  by  GKS  of  a  CGM  of 
catagorm  GKSM  is  wal  dafinsd. 

E.8.2  Suggastlon  for  Intarpratation  of  COM  Font  Information  by  GKS 

GKS  anvironmants  intarprating  a  CGM  spacify  fonts  with  a  font  numbar.  It  is  assumad  that  GKS  maintains  <i 
list  associating  positiva  font  numbars  with  a  GKS  ragistarad  font  nama  or  idantiiiar.  Privata  font  numbars 
(l.a.  ngativa  vaiuas)  must  ba  maintainad  in  an  implamantation  dapandant  list  of  associations.  As  tha  FONT 
LIST  alamant  is  artarpratad,  an  addKaional  list  must  ba  maintainad  that  assedatas  indaivkiualfont  names 
spacifiad  in  tha  CGM  with  a  font  indax.  Tha  subsequent  intarpratation  of  tha  MODIFY  FONT  LIST  alamant 
will  result  in  charigas  or  additions  to  this  Ksl.  Whan  lha  TEXT  FONT  INDEX  alamant  is  intarprattad,  tha  font 
nama  assodatad  with  tha  font  irxiax  is  datarmir>ad  from  tha  list  of  currently  used  fonts,  ttia  font  nama  is 
used  to  datormina  tha  GKS  foot  numbar  assodatad  with  this  font  from  a  list  of  GKS  ragistarad  fonts.  This 
font  numbar  Is  used  as  tha  font  parameter  of  tha  TEXT  FONT  AND  PRECISION  function.  Tha  value  of  the 
pracision  parameter  is  taken  from  tha  TEXT  PRECISION  alamant  that  directly  follows  each  TEXT  FONT 
INDEX  alamant  in  a  CGM  with  category  GKSM. 

E.9  Character  Vectors 

A  matafila  of  GKSM  catagory  writas  tha  CHARACTER  HEIGHT  and  CHARACTER  ORieiTATlON  as  a  pair  in 
tha  CGM  in  that  order.  One  intarpratation  this  will  return  lha  charactar  vardor  information  back  to  tha  GKS 
application  using  tha  following  mapping; 

(CH.CO)  maps  to  CH'Charactar  Up  Vector  CH'Character  Basa  Vactor 


I  Charactar  Up  Vactorj  jCharactar  Up  Vactorl 
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Th«  foHowkig  anrwx  fotnms  a  rww  arvMx  F. 

F  Formal  Grammar  of  the  Functional  Specification  of  the  CGMEXTl 
Category 

NOTE  •  This  annax  is  not  part  of  tha  Standard;  it  Is  indudad  for  information  purposas  only. 


F.1  Introduction 

This  grammar  is  a  formal  dafinition  of  a  standard  COM  axtandad  syntax.  Tha  arwodlng>ir>dapandant  arxf  the 
ancoding-dapandant  productions  ara  saparatad,  and  thara  ara  subsadions  showng  tha  syntax  of  each  of 
tha  standardizad  ano^ng  schamas.  Dataiis  on  tha  ancoding  of  tarminai  symbols  can  ba  found  in  parts  of 
this  Standard  that  daal  with  tha  particular  ancoding  schamas. 

F.2  Notation  Used 


<symbol> 

<SYMBOl> 

<symboi>* 

<symbol»-t> 

<symboi>o 

<symbol>(n) 

<symbol-1>  :>  <symbol>2^ 
<symbol-1>  |  oymbd^ 
<symbol:  maanlng> 
(oommant) 

F.3  Detailed  Grammar 

F.3.1  Mataflla  Struetura 


-  nonterminal 

•  tarmind 

•  0  or  more  oocurrancas 

•  1  Of  more  oocurrancas 

-  optional  (0  or  1  oecurranoaa) 

•  axMliy  n  oocuiranoas,  ivi2.3.... 

•  symbol-1  has  tha  syntax  of  symbol-2 

•  aymbol-1  or  altsmativaiy  symbol-2 

•  symbol  with  tha  stated  meaning 

-  explanation  of  a  symbol  or  a  production 


<matafila> 

<matafila  contents> 

<sxtra  siamant> 
<picture> 


<picture  content> 

<identifier> 
<picture  element> 


<BEGINMETAFILE> 

<{dantiflar> 

<matafila  dascriptoo 
<matafHa  contants> 

<END  METAFn£>. 

<axtra  alamant>* 

<pictura> 

<extra  alamant>* 

<axtamai  alamanb* 

I  <ascapa  eiamant> 

<8EGIN  PICTURE> 
<idantifiar> 

<pictura  descriptor  elament>' 
-eBEGIN  PICTURE  BODY> 
<pictura  contant>* 

<eiD  PICTURE> 

:>  <pictura  alamant> 

I  <sagmont> 

<stpng> 

:;ai  <control  elemant> 

I  <graphicat  elamant> 

I  <attribute  siamsnt> 
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<ascap«  •(•manby 
<axtamai  aiafnanl> 
oagmant  alainant> 


<sagniant> 


<BEGiNSEGMENT> 
oa^ant  nania> 
<aHgibla  pictura  alamant>* 
<B40SEG»«IENT> 


oagmant  nama> 


<intagar> 


<afigibia  ptetura  alamant> 


<arigtt>ta  local  aagmant  pictura  alamant> 
<aligtbla  global  aagmant  pictura  alamant> 


<al1gibla  local  sag  pictura  alani>  <axpand  from  stata  tabla> 

<allgibla  global  sag  pictura  aiam>  <axparKi  from  stats  tabla> 


F.3.2  Mataflla  Oaaerlptor  Elamants 


<matafita  daacnptor> 


<idantiflcatfon> 

<eharaetari8tlcs> 


<idantlfieatlon> 

<matafla  catagory> 
<niatafila  daacrfptfan> 
<eatagory  anumaratad> 

<cfiaractaristlca> 

<alamant  list> 


<METAF!LEVERSION> 

<lntagar> 

<matafila  da8cr1ptlon>o 
<matafila  eatsgory>o 

<METAFE£CATEGORY> 
<eatagory  anumaratad> 


<MErAF!LE0ESCRIPT1ON> 

<strlng> 


<CGM> 

I  <CGMEXT1> 
I  <GKSM> 


<alamant  list> 

<optlonal  baser  olmt>* 

<METARLEELB^ENTLIST> 
<alamsnt  nama>* 


<optiorwU  baser  almt>  <VDC  TYPE> 

<vbc  typa> 

I  <MAXIMUMCCXOURINDEX> 

<coiour  inbax> 

I  <CCX.OUn  VALUE  EXTENT> 

<rab  graan  blua><2) 

I  <METAR.E  DEFAULTS  REPtACEMENT> 
<alamant  bafault>-t- 
I  <FONTUST> 

<font  nama>-t- 

1  <CHARACTERSETLIST> 

<charactar  sat  bafinilion>^ 

I  <CHARACTER  COOING  ANNOUNCER> 
<coding  tachniqua  anumaratab> 

I  <scalar  pracision>* 

I  <ascapa  alamant> 

I  <axtamal  aiamant> 

I  .«MAXIMUMVDCEXTENT> 

<point>  (2) 

I  <SEGMENT  PRIORITY  EXTENT> 
<minimum  axtant> 


« 
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<maxitnum  «xtant> 


<vdc  tyM>  "■  <INTEGER> 

1  <REAL> 

<«l«nwitd*fault>  eontroi  alwnanb. 

I  <pictur«  dascriptor  alatnan^ 

I  <attributa  a<amant> 

I  <aacapa  aiamant> 

<foot  nama>  <sfring> 

<chwactaf  sat  dafkiitten>  :>  <char  sat  anuniafatad> 

<daslgnation  saquanca> 

<indax>  <standard  (ndax  vatua> 

I  <privata  indax  vaiua> 

<standard  Indax  valua>  <noo-nagatlva  intagar> 

<nofwiagativa  intagaf>  <lntagar>  (^aatar  «  aqua!  to  0} 

<positiva  lntagar>  :>  <intagaf>  (graalar  than  0} 

<privata  indax  vafua>  <nagatlva  lntagar> 

<nagatlva  intagar>  "■  <intagaf>  ^MlhanO} 

<positiva  indax  vaiua>  <positlva  Intagao 

<char  sat  anuniafatad>  ^  CHAR> 

I  <96CHAR> 

I  <MIA.TVBYTE94CHAR> 

I  <MULT1-amg6CHAR> 

I  <COMP1.ErECOOE> 

<eoding  tachniqua  anufnaratad>  <BASIC  7-8IT> 

I  <BASIC^BIT> 

1  <BCTOff)ED7-en’> 

I  <BCTB«)SDMrr> 

<dasignation  aaquanca>  <8tring> 

<acalar  pracision>  <WTEGER  PRECISIO^fe 

<intagar  precision  valua> 

1  <REAL  PBECISION> 

<raai  pracision  vaJua> 

I  <INDEX  PRECiSION> 

<indax  pracision  vaiua> 

I  <COLOtJR  PRECISION> 

<cak)ur  precision  vaiua> 

I  <COLOUR  INDEX  PRECISION> 

<ooi  indax  pracision  vaiua> 

(thasa  aiamants  have  encoding} 

{dapandant  paramatars  } 

<aligibla  control  alament>  <V0C  PRECISION> 

I  <AUXI.IARYCOLOUR> 

1  <TRANSPARBICY> 

1  <aJP  RECTANGLE> 

I  <CUP  INOICATOR> 

I  <VDCEXTBn'> 

I  <DEVICEV!EWPORT> 

I  <0EVICE  VIEWPORT  SPECIRCATION  MODE 
1  <DEVICE  VIEWPORT  MAPPING> 

I  <SET  DEFERRAL  MOOE> 

I  <UPDATE> 

I  <IMPLICIT  EDGE  VISIBILrTY> 


<point>  <vdc  v«I(m>  (2) 

oninimum  •xtant  <inte9«r> 

<nMxkmjm  •xtent>  :>  <int«g«r> 

F.3.3  Pletur*  Descriptor  Elsmsnts 

<picturs  descriptor  element  <SCALINQ  MOOE> 

oealingspec  mode> 

<metrfe  scale  factor> 

I  <C0L(XJRSB.ECT10NM00E> 

<colour  select  mode> 

(  ui«  WIDTH  specifk:ationmode> 

<specmoda> 

I  <MARKB)  SIZE  SPECIFICATION  MOOE> 
<apeemode> 

I  <eX3E  WIDTH  SPEaFICATIONMODE> 
<apeefflOde> 

I  <vDCEXTefr> 

<poirTb<2) 

I  <SACXGROUNDCOLOUR> 

<red  green  blue> 

I  <escape  e<ement> 

I  <exte(^  element 

<oalour  select  mode>  <MDEXEO> 

I  <OIRECT> 

<scaling  spec  mode>  :>  «ABSTHACT> 

I  <METniC> 

•onirirle  scale  faetor>  :>  <ntd> 

<apecnK)de>  <A8SOLirrE> 

I  <SCALEO> 

<poin^  <vdc  yalue>  (2) 

F.3.4  Control  Elements 

<control  element>  <vdc  precisk)n> 

t  <AUXtlARYCOLOUR> 

<colour> 

I  <TRANSPARENCY> 

<on-o(f  Indicator  enumerated> 

I  <CUP  ReCTANGLE> 

<point><2) 

I  <CUP  INOtCATOR> 

<on-otf  indicator  onumerated> 

1  <VOCEXTH^> 

<polnt><2) 

I  <OEVICEV1EWPORT> 

<devioe  point>/2) 

I  <OEVICE  VIEWPORT  SPECIRCATION  MODE 
<VSU  speclfier> 

<metric  scale  (actor> 

I  <OEVICE  VIEWPORT  MAPPING> 

<isotropy  llag> 

<horizontal  atignmont  flag> 

^vertical  alignment  flag> 

I  <SET  DEFERRAL  MOOE> 

<defen'al  mode  enumerated^ 
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I  <MAKE  PICTURE  CURReiT> 

I  <PREPAREV1EWSURFACE> 

<torc«  hard  copy  advanoa> 

I  <UPOATE> 

<updata  raganaration  flag  anumaratad> 
I  <MOOIFYFOMrLIST> 
otarting  indax> 

<tont  nama  liat> 

I  <MCX)IFY  CHARACTER  SET  UST> 
otarting  indax> 

<charactar  sat  dafinHion  list> 

I  <BEGINRGURE> 

I  <B40HGURE> 

I  <NEWRE(3I0N> 

I  <IMPLJCrrEDGEVISIBiLJTY> 

Kknpfictt  adga  visMlity> 

I  <SAVEPRlMrnVEATTRBUTES> 

<attributa  sat  nama> 

I  <RESTORE  PRIMITIVE  ATTRIBUTES> 
<attribtita  sat  nanM> 

I  <OeLETEATTRBUTESET> 

<attri>uta  sat  nama> 

<on-off  indicator  anuinaratad>  <0N> 

I  <OFF> 


<colour> 

<vdc  praci3ion> 

'cdavica  paint> 

<VSU  spacifiar  anumaratad> 

onatric  scaia  factoo 
<iaotropy  flag  anumaratad> 

<horjz  align  flag  snumar> 

<vart  align  flag  onumar> 

<dafarral  moda  anumaratad> 

<forca  hard  copy  advanca 
anumaratad> 


:>  <ealour  indax> 

I  4od  graan  bkia> 

<VDC  INTEGER  PRECIS10N> 

<vde  intagar  pradsion  valua> 

I  <VDCREM.PRECISION> 

<vdc  raai  pracialon  valua> 

{ttwaa  aiamants  hava  ancoding) 

(dapandant  paramatara  } 

'ji.<rsal>{2) 

<FRACT10N  OF  DEFAULT  DEVICE  VIEWPORT> 
(  <MIUJMETRES  WITH  SCALE  FACTOR> 

I  <PHYSICAL  DEVICE  UNITS> 

I  <raal> 

<NOTFORCED> 

I  <FORCH>> 

<LEFT> 

I  <CENTRE> 

I  <RIGKT> 

<BOTTOM> 

I  <CENTRE3- 
I  <TOP> 


<ASAP> 
I  <BNI> 

I  <AST1> 


<FORCEHARDCOPY> 

<CONDmONAL> 


I 
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<updat«  regeneration  flag 
anumaratad> 

otaiUng  index> 

<font  name  Rst> 

<character  set  def.  Iist> 
<impiicit  edge  vis  enumer> 

<attr<biite  set  name> 

F.3.5  Qraphleal  Elements 
<graphical  element> 


<polypoint  element> 


<point  list> 

<po<nt  pair  list> 

<point  pair> 

<point  edge  pair> 

<paint  edge  pair  nst> 
<adge  out  flag> 

<text  olement> 

<restricted  text  element> 


:>  <PSIRDRM> 

I  <POSTPONE> 

:>  <index> 

<(ontname>-»- 

:>  <character  set  definition>«- 

<OFF> 

I  <ON> 

<strtng> 


::m  <polypoint  element> 

I  <text  element 
I  <oell  element> 

I  <g^eietnen^ 

I  <rectar>gle  element 
I  <eircuiar  eiement> 

I  <eHipticai  element 
I  <pixel  array  eiement> 

<POLYUNE> 

<poMpair> 

<pointlist> 

I  <OISJOINTPO(.YUNE> 
<pointpair> 

<point  pair  Hst> 

I  <Pa.YMAHKER> 

<point> 

<pointr«st> 

I  <POLYGON> 

<point><3) 

<pointnst> 

I  <PCXYGONSET> 

<poim  edge  pair><3) 
<point  edge  pair  list> 

<point>* 

<pointpair>* 

<pofrT^2) 

<pointxedga  out  flag> 

"m  <point  edge  pair>* 

<INViSi6LE> 

I  <VISiBLE> 

I  <CLOSE  INVISIBLE> 

I  <CLOSE>!SIBLE> 

<TEXT> 

<point> 

<text  tail> 

I  <restricted  text  •lement> 

<RESTRIC7ED  7EXT> 
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<«xt«nt> 

<t*xt  tail> 

<final  character  tist> 

<nonfinal  charactar  Rs^ 


oparmad  taxt> 
<oan  alaman^ 


<local  oofcMir  pracision> 


<gdp  alamant> 


<gdp  idantifiao 
<ractangia  a<amant> 

<circular  alainant> 


<radius> 


<axtant> 

<po<nt> 

<taxt  taR> 

<vdc  valua><2) 

<final  charactar  list> 

I  <nonfinal  charactar  Kst> 

<RNAL> 

<eharaetar  Bs^ 

<NOTnNAL> 

<atrlng> 

<eharactar  attribute  a(a(nant>* 
<apannad  tax^ 

<APPe<D7EXT> 

<taxt  taB> 

<CELLARRAY> 

<po<fib^3) 

<intagar><2) 

<local  eoiour  pradsion> 
<oolour><inla^1  x  intagar2) 

{this  alamant  has  an  encoding) 

(dapandant  paramatar  ) 

<oolour  pradahxi  vahja> 

I  <oai  index  pradaion  vaiua> 

I  <dafauH  col  practaion  indicatoo 

<GOP> 

<gdp  idantffiar> 

<point  ist>* 

<dataracord> 

::m  <intagar> 

:>  <RECTANGL£> 

<pointpair> 

<CIRCLE> 

<point> 

<radius> 

I  <CIRCULAR  ARC  3  PaNT> 

<<point><3) 

1  <CIRCULARARC3POn^CLOSE> 
<poin^3) 

<ctosa  typa> 

I  <aRCULARARCCBITRE> 

<point> 

•cvdc  vaiua>{4) 

<radhis> 

I  <CIRCULAR  ARC  CENTRE  CLOSE> 

<dosa  typa> 

I  <CIRCULAR  ARC  CENTRE  BACKWAROS> 
<poirTt> 

<vdc  vaiua><4) 

<radius> 

<non-nagatlva  vdc  valua> 
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<non-n«gativ«  vdc  vaiu«> 
<doM  typ«> 


<vdcvaiu«>  {grMtar  or  equal  to  0) 


<ailip4ieal  aiafnan^ 


<plxa(  array  alafnant> 


<array  (fltnansion> 
<vaMxranga> 

<yaBd>  rartgo> 

<x  sesM> 

<yaeala> 

<oolour  sp#d1lars> 

F.3.6  Attribute  Elamants 
<primKl<ra  attrftiuta  ala«n> 


<lin8  attiibuta  alamanb* 


<siza  valua> 


<PIE> 

I  <CHORD> 

<BJL1PSE> 

<poin^3) 

I  <eLJJPT1CALARC> 
<poin^3) 

<vde  vdua><4) 

I  <ELUPT1CALARCCL06E> 
<point><3) 

<vde  vaiua><4) 

<eio8a  typa> 

<PI)S.ARRAY> 

<point> 

<array  diinanston> 
<vald  xranga> 
<vaMyranga> 
<xscat^ 

<y  acaia> 

<oolour  3pad(iars> 

-dntaganKa) 

<intagaf><2) 

<lntagar><2) 

:>  <iritaqar> 

<Magar> 

:>  <afray> 


“m  <lna  attribute  ataman^ 

I  <fnarkar  atbibuta  alafnant> 

I  <taxt  attribute  alatnant> 

I  <finad  area  attrAruta  alainarit> 
I  <ookHir  table  alafnant> 

I  <aspact  source  flags> 

I  <repreaarTtation  element> 
i  <pi^  identifier> 

I  <drawing  inode> 

<UNE  BUNDLE  INOEX> 
<posltive  indax> 

I  <LWE7YPE> 

<ir«tex> 

I  <IJNEWIDTH> 

<slze  value> 

I  <LINECOLOUn> 

<calour> 

:>  <norvnagative  vdc  vaiue> 

I  <rK>n-negadve  reaJ> 


<r>ofvnegative  real> 
<inarker  attribute  elament> 


::m  <real>  (greater  or  equal  to  0} 
<MARKER  BUNDLE  INDEX> 


<positiv»  ifxtox> 

1  <MARKERTYPE> 
<ind«x> 

I  <MARK^SIZE> 
<size  valu«> 

I  <MARKB^COLCXIR> 
<colour> 


attribute  akMnant>  <chaf  attribute  elenient> 

I  <abing  attribute  eiement> 

<ctiar  attribute  eleinent>  <TEXT  BUNDLE  NOEX> 

<positive  irtdex> 

I  <TEXTRDNTINDB<> 

<positive  lrKiex> 

I  <CHARACTER  EXPANSION  FACTOR> 
<reai> 

1  <CHARACTfflSPAaNG> 

<reai> 

1  <TEXTCXXOUR> 

<ooloi^> 

I  <CHAR/^nrBtHBGHT> 

-cnon-negative  vdc  value> 

I  <CHARACTB)0RB<TAT10N> 

<vde  value><4) 

I  <CHAPACTBfSEr»IDEX> 

<positive  inde]& 

I  <ALTERNATECHARACTB)SETtNDEX> 
<positive  lndex> 


<string  attribute  element 


<path  enumerated> 


<text  precision  enumerated> 


<horizcintal  align  enumerated> 


<verticai  align  enumerated> 


<continuous  align  value> 


<TEXT  PAT>fe 

<paih  enufneratad> 

I  <TEXrPRECISION> 

<text  predaion  anumerated> 

I  <TEXTAUGNMe(T> 

<horizQntai  align  enunierated> 
<vertical  aflgn  enunieratsd> 
<cantinuous  aOgn  vaJue>  (2) 

<RIGHT> 

I  <LEFT> 

I  <UP> 

I  <OOWN> 

<srrRMG> 

I  <CHARACTSl> 

I  <STROKE> 

<NOPMALHORIZONTAL> 

I  <LEFT> 

I  <C0<TnE> 

I  <RIGHT> 

I  <CONnNUOUS  HORIZONTALj> 

<NORMALVERrnCAL> 

I  <TOP> 

I  <CAP> 

I  <HALF> 

I  <BASE» 

1  <BOTTOM> 

I  kCONTTNUOUS  VERnCAL> 
<real> 
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<fili«d  vaa  attributa  alani> 


<intafior  atyta  anumaratad> 

<ookMjr  tabla  a(a(nant> 

<starting  indax> 

<aspact  sourca  llags> 

<as(  pair> 

<asf  typa> 


<Ra  BUNDLE  INOEX> 

<positiva  indax> 

I  <WrERIOR  STYLE> 

<intanar  styla  anumaratad> 

I  <FnJLCOLOUR> 

<calour> 

I  <HATCH»JD0(> 

<indax> 

I  <PATTERN  MDEX> 

<positiva  indax> 

I  <BX3E  BUNDLE  MOEX> 

<positiva  indax> 

I  <EDGETYPE> 

<indax> 

I  <S)GEWiDTH> 

<siza  vaiua> 

I  <EDGECOLOUR> 

<eotour> 

I  <EOGE  VtSBILrTY> 

<on-off  ifxflcator  anumaratad^ 

I  <«FU.REFEReiCEPONT> 

- * 

<pOw1^ 

I  <PATTERNTABLE> 

<poaittva  lndax> 

<irrtagar><2) 

<loeal  ootour  pradsion> 
<oalo(ff><)ntagart  xintagar2) 
(Itw  atamant  haa  an  anoodng) 
(dapandant  paramatar  ) 

I  <PATrE!^SiZE> 

<vde  vaiua><4) 


:>  <HCXJLOW> 

I  <SOUD> 

I  <PATTERN> 

I  ^TOb. 

I  <a<PTY> 

<C0L0URTA8LE> 
ota/ting  indax> 
‘tfad  graan  bhja>4- 


<caiour  indax> 

<ASPECT  SOURCE  Rj4GS> 
<aaf  paii>^ 


<asf  typa> 
<asf> 


<UNETYPEASF> 

1  <LINE  WIDTH  ASF> 

I  <L1NE  COLOUR  ASF> 

I  <MARKERTYPEASF> 

I  <MARKERSiZEASF> 

1  <MARKER  COLOUR  ASF> 

I  <7EXTF0NTASF> 

I  <TEXT  PRECISION  ASF> 

I  <TEXT  FONT  AND  PRECISION  ASF> 

I  <CHARACTER  EXPANSION  FACTOR  ASF> 
I  <CHARACTERSPACWGASF> 

I  <TEXT  COLOUR  ASF> 

I  <INTERIOR  STYLE  ASF> 

I  «RLL  COLOUR  ASF> 
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I  <HATCH  INDEX  ASF> 

I  <PATTERN  INDEX  ASF> 

1  <EDGETYPEASF> 

I  <eX3E  WIDTH  ASF> 

I  <EDGE  COLOUR  ASF> 

<asf>  <INDIVIDUAL> 

I  <BUNDLB>> 

<r«pr«s*ntation  •icman^  ::<■  <LINE  R^RESENTAT10N> 

<positiv«  ind*x> 

<ind«x> 

<siz«  valu«> 

<colour> 

I  <MARKERRB>RES0fTATKDN> 
<positiv«  ind«x> 

<ind«x> 

<siz0  v«lu«> 

<calour> 

I  <TEXTRB>RESBrrAT10N> 
<posMv«  {nd«x> 

<ind«x>  {fon^ 

<toxt  prvdsion  •nufnM’at«d> 
<r«iU>  {character  apadng} 
<raai>  jaxpatteksn  factor) 
<colour^ 

I  <nLL  REPRESBOATKIhb. 

<posftiva  indax> 
interior  styte  aninnaratad> 
<dndax>  (hatch  indas^ 
<poaHiva  indax>  (pattern  indax) 
<^our> 

I  <EDGERB>RESe4TAT10N> 
<po3<tiva  indax> 

<indax> 

<aiza  vahia> 

<coiour> 

I  <PATrERNTABt£> 

<positiva  indax> 

<jntegar>(2} 

<iocai  colmr  practsion> 
<colour><irTtagar1  *lntagar2) 

(this  alafnant  has  an  ancoding) 
(dspandant  paramatar) 

1  <COLOURTABLE> 

<startir)g  indax> 

<rad  graan  blua>4- 

<pick  (dantifiar>  <PICK  IDEMTIRER> 

<intagar> 

<drawing  moda>  <DRAWING  MODE> 

<intagar>  (0-15) 


F.3.7  Escapa  Eiamants 

<ascapa  alamant>  <ESCAPE> 

<idantiiiar> 
<data  raoord> 

<idantifiar>  <intagar> 


86 


« 


F.3.8  External  Elamants 


<axtamal  alaman^  :>  <MESSAGE> 

<actton  flag> 
<s1rlng> 

I  <APPUCATTON  DATA> 
<intagar> 

<daUi  racord> 

•caction  flag>  <YES> 

I  <NO> 


F.3.0  Sagmant  Elamants 
oagmant  alafnant> 


<copy  tranaformation  matrix> 
<transfomiation  matrix> 

<old  sagmant  nama> 

<naw  segment  name> 

<impHcit  sag  ragen  mode  anum> 


<REOP^SEGMBn’> 
oagmant  nama> 

I  <COPYSEGM&IT> 
oagmant  nama> 

<copy  transformation  matrtx> 

I  <OQ£TESEGMBn> 
oagmant  nama> 

I  <0e.ETEALi.SEGMB4TS> 

I  <RBIAMESEGMB<T> 
old  sagmant  nama> 
oaw  sagmant  nama> 

I  <RB}RAWALLSEGMa4TS> 

I  <IMPUCn'SEGMB^REGB4ERAT10NMCX)E> 

<impBdt  sagmant  raganaralion  moda  anumaratsd> 
I  <INHERfTANCE  FLT^ 

<fltar  salaction  attrutNJta  dalaignator>+ 
oatting> 

I  <SeGK®n'TRANSFORM> 
oagmant  nama> 

<transfo>matlon  matrfeo 
I  <SEGMEKTVISIBItJTY> 
oagmant  nama> 

<visibiiity  anumaratad> 

I  <SEGMefrHIGHUGHnNG> 
oagmant  nama> 

<highl(ghting  anumaratsd> 

I  ^SEGMENT  DISPLAY  PRIORITY> 
oagmant  nama> 
oagmant  display  prionty> 

I  <SEGMBTr  OETlCTABILrTY> 
oagmant  nama> 

<datsctabinty  anumaratad> 

I  <SEGMEMT  PICK  PRIORrrY> 
oagmant  nama> 

<sagmant  pick  priority> 

<transtonnation  matrix> 

:«  <raal>  (4) 

<vdc>  (2) 

:>  <jntagar> 

;>  <intagar> 

<SUPPRESSED> 

I  <ALLOWED> 


« 
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<fiK«r  selection  att  des  enu(n> 


oetting  enunnerated> 

<transfonnation  matrix> 
<visibility  enumerated> 

<hlghHghting  anumeratecl> 

<aegfnent  dtspalay  priortty> 
detectability  enumeratad 

oegment  pick  priority> 


<LINE  ArrRIBLrrE> 

1  <MARKERATTRIBUTES> 

1  <TEXTATTRIBLrrES> 

I  <CHARACTERATTRIBUTES> 
I  <FttJ.ATTRIBLmS> 

1  <EDGEATTRBUTES> 

I  <PATTe^NATTRIBUTES> 

1  <PATTS»NATTOBareS> 

I  <CUPCONm(X> 

1  <ouTPurcoNTnot> 

I  <ALL> 

<STATE_LIST> 

I  <SEGMENT> 

<reai><6) 

<VISIBLE> 

I  <INVISiBLE> 

<NORMALk 
I  <HI6HLIGHTED> 

:><integer> 

<OETB:rrABLE> 

I  <UNOETBrrABLE> 

:>  <integer> 


F.4  Terminal  Symbols 

The  fofcwino  are  the  terminala  in  Me  grammar. 

Their  representation  is  dependent  on  the  erwxxling  scheme  used. 

In  annex  A  o(  the  subsequent  parts  of  this  StarKtard.  these 
encoding-dependent  symbols  are  further  described. 

<eiement  name> 

<integer> 

<real> 

<vdc  vaiue> 

<string> 

<colour  indsx> 

<red  green  blue> 

<integer  prec  vaiue> 

<real  prec  value> 

<tndex  prec  vaiue> 

<coiour  prec  vaiue> 

<coi  index  prec  value> 

<default  col  prec  indicator> 

<vdc  integer  prec  value> 

<vdc  real  prec  value> 

<colour  list> 

<data  record> 

<devics  point> 

<name> 

oegment  name> 
ottribute  set  name> 
eviewport  specification  point> 

The  CGM  extended  opcodes  are  erKoding  dependent.  A  complete  list  of  them  can  be  found  in  the 
productions  for  <slement  name  enumerated>  below. 


« 
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Th«  •numcratsd  types: 


<CGM> 

<CGMEXT1> 

<GKSM> 

<iNTEGER> 

<REAL> 

<0N> 

<OFF> 

<INOEXED> 

<OIRECT> 

<ABSrmACT> 

<METRIC> 

<ABSOLUTE> 

<SCALEO> 

<94CHAR> 

<g6CHAR> 

<MULT1-8YTE  94  CHAR> 

<MULT1-BYTE  96  CHAR> 

<(X)MP(.ETECOOE> 

<BASic  7-err> 

<fiAsic  8-Brr> 

<EXTB40E07<8rr> 

<EXTEN0S)8«rr> 

<fflACnON  OF  Off  AULT  DEVICE  VIEWPORT> 

<MUJMETnES  wrm  scale  factor> 

<PHYSiCAL  DEVICE  UNrTS> 

<NOTPORCEO> 

<FOnCB)> 

<LEFT> 

<RIGHr> 

<Ce(TRE> 

<BOTTOM> 

<TOP> 

<«ASAP> 

<BNI> 

<AST1> 

<FORCEHAnDCOPY> 

<CONDmONAL> 

<SUPPRESSEO> 

<ALLOWED> 

<POSTPONE> 

<Pe^FORM> 

<CONDinONALLY> 

<ALWAYS> 

<INVISIBLE> 

<VISIBLE> 

<CLOSE  INVISIBLE> 

<CLOSE  VISIBLC> 

<PIE> 

<CHORD> 

<FINAL> 

<NOTFlNAL> 

<INDIVIDUAL> 

<BUNDLED> 

<HOLLOW> 

<SOLID> 

<PATTERN> 

<HATCH> 

<EMPTY> 

<STRING> 

<CHARACTER> 

<STROKE> 


89 


<RIGKT> 

<LEFT> 

<UP> 

<DOWN> 

<NORMAL  HORIZONTAL 
<CENTRE> 

<CONnNUOUS  HORIZONTAL 
<NORMAL  VERTICAL 
<TOP> 

<CAP> 

<HALF> 

<BASE> 

<BOTTOM> 

<CONTTNUOUS  VERTICAL 
<yES> 

<NO> 

<UNE7YPEASF> 

<1JNE  WIDTH  ASF> 

<L1NE  COLOUR  ASf=> 

<MARKERTYPEASF> 

<MARKERSIZEASF> 

<MAflKER  COLOUR  ASI=> 
<TEXTBDNTASF> 

<TEXT  PRECISION  ASF> 

<TEXT  FONT  AND  PRECISION  ASF> 
<CHARACTS^  EXPANSION  FACTOR  ASF> 
<CHARACTER  SPACWG  ASF> 

<TEXT  COLOUR  ASF> 

-dNTERIOR  STYLE  ASF> 

<HAT1CH  WOEXASF> 

<PATTERN  INDEX  ASF> 

<FIU.  COLOUR  ASF> 

<SX3ETYPEASF> 

<aX3E  WIDTH  ASF> 

<EDGE  COLOUR  ASF> 
<L1NEATTRBUTE> 

<MARKER  ATTRIBUTES> 
<TEXTATTRIBUTES> 

-eCHARACTER  ATTRIBUTES> 

<F!LL  ATTRIBUTES> 

<EDGE  ATTRI8UTES> 

<PArnSIN  ATTRieUTES> 

<pattern  attributes> 

<CLIP  CONTROL 
<OUTPUT  CONTROL 
<ALL 

<STATE  LIST 
<SEGMBTT> 

<VISIBLE?> 

<INVISIBLE> 

<normal 

<HIGHLIGKTEO> 

<DETECTABLE> 

<UNDETECTABLE> 


<element  name  enumefated>  <BEGIN  METAFILE> 

I  <END  METAFILE> 

1  <BEGIN  P1CTURE> 

1  <BEGIN  PICTURE  BODY> 
I  <ENDP1CTURE> 

I  <BEGIN  SEGMENT> 

I  cENO  SE<»^ENT> 

I  <METARLE  VERSION> 
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<METARLE  CATEGORY> 

<MErARLE  0£SCRIPTION> 

I  <VDCTYPE> 

<INTEGER  PRECISION> 

<REAL  PREC)SION> 

<INOEX  PRECIStON> 

<COLCXJR  PRECISION> 

<COLOUfl  INDEX  PRECISION> 

<MAXIMUM  COLOUR  INDEX> 

<METAFLE  UST> 

<METAF!LE  Off  AULTS  REPlACB«eR’> 
<FONTlJST> 

<CHARA(rriR  SET  LJST> 

<GHARACT51  COD»4G  ANNOUNCER> 
<MAXMUM  VOC  EXTBn‘> 

<SEGM0rr  PRIORTTY  EXTBR'> 
<SCAL1NGMOOE> 

<COLOUR  SB-ECmON  MOOE> 

<UNE  WtOTH  SPECiRCATION  MOOE> 
<MARKER  SIZE  SPECIFICATION  MOOE> 
<aX3E  WlOrm  SPECIFICATION  MOOE> 
<VDCEXTBIT> 

<BACKGROUNO  COLOUR> 

<VDC  INTEGSR  PREaSION> 

<VDC  REAL  PRECISION> 

<AUXLIARY  COLOUR> 

<TRANSPAReiCY> 

<CUP  RECTANGLE> 

<CUPINDiCATOR> 

<OEVICEVIEWPORT> 

<DEVICE  VIEWPORT  SPECIFICATION  MODE 
<DEVICE  VIEWPORT  MAPPING> 

<SET  DS5WVL  MOOE> 

<UPOATE> 

<MOOIFYFONTUST> 

<MOOIFY  CHARACTER  SET  UST> 

<eEGIN  RGURE> 

<e4DRGURE> 

<NEWREGiON> 

<«(IPUCrT  EDGE  VISIBILTY> 

-cSAVE  PRIMITIVE  ATrRIBUTES> 

<RESTOflE  PRIMmvE  ATTRIBUTES> 
<DS.ETE  ATTRBUTE  SET> 

<POLYUNE> 

<DISJOINT  POLYLINE> 

<POLYMARKER> 

<TEXT> 

<RESTRIC7ED7EXT> 

-sAPPENDTEXT> 

<PCLYGON> 

<POLYGONSET> 

<CSLL  ARRAY> 

<GDP> 

<RECTANGLE> 

<CIRCLE> 

<CIRCULAR  ARC  3  POINT> 

<CIRCULAR  ARC  3  POINT  CLOSE> 
<aRCULAR  ARC  CENTRE> 

<CIRCULAR  ARC  CENTRE  CLOSE> 
<CIRCULAR  ARC  CENTRE  BACKWARDS> 
<ELLIPSE> 

<ELLIPnCALARC> 

<EU.:P'nCAL  ARC  CLOSE> 

<PIXEL  ARRAY> 


* 
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I  <1JNE  BUNDLE  INOEX> 

I  <UNETYPE> 

I  <UNEWIOTH> 

I  ;iJNECOLOUR> 

I  <MARKER  BUNDLE  INOEX> 

I  <MAnKERTYPE> 

I  <MARKERS1Z£> 

I  <MARKERCOLOUR> 

I  <TEXT  BUNDLE  WDEX> 

I  <TEXTFONTtNDEX> 

I  <TEXT  PRECISK3N> 

I  <TEXTFOMrAfffiPRECISION> 

I  <CHAflAC7ER  EXPANSION  FACTOfb. 

I  <CHARACTBtSPACMG> 

1  <TEXTCOLOUR> 

I  <CHARACTHtHaGHT> 

I  <CHARACTB)  0Rien’AT10N> 

I  <CHAflACnERVECTORS> 

1  <TEXTPA*rH> 

I  <TEXTAL1GNMENT> 

I  <CHARACTERSErMDEX> 

I  <ALTBVIATECHARACTB^SETINDEX> 

I  <Fn±  BUNDLE  NOEX> 

I  <iNrBaoRsnmjB. 

I  <m.cxxouR> 

I  <HATCHMDEX> 

I  <PATTERN  »®EX> 

I  <eDGEBU(«}LEMDEX> 

I  <SX3E'rYPE> 

I  <S)GEWH)1H> 

I  <EDGECOLOUR> 

I  <EDGE  ViSBILrrY> 

I  <niLREFS®ICEPONT> 

I  <PATreV4TAflLE> 

I  <PATTBWSCZ&- 
I  <COLOURTABLE> 

I  <ASPECT  SOURCE  FLAGS> 

I  <PICK  IDe4nRER> 

I  <lJNERS>RESENTA'nON> 

1  <MARKERREPRESB^ATTON> 

I  <TEXTREPRES0irA7TON> 

1  <RLLRB»RES»n’ATION> 

I  <e3GE  REPRESe4TAT10N> 

(  <PICK  IOENnnER> 

I  <DRAW1NGMOOE> 

I  <REOPe<SEGMBR’> 

I  <COPY  SEGMBfr> 

I  <DeLETESEGM0rr> 

1  <OQ.ETEALLSEGMENT> 

I  <Re4AMESEGMB^> 

I  <REDRAW  ALL  SEGMENTS> 

1  <IMPUCn’ SEGMeiT  REGENERATION  MOOE> 
I  </NHERrrANCE  FILTER> 

I  <SEGMeRrTRANSFOflM> 

I  <SEGMENTVISIBIL]TY> 

I  <SEGMefrHIGHLIGKnNG> 

I  <SEGMENT  DISPLAY  PRIORrrY> 

I  <SEGM0R'DETECTABILrrv> 

I  <SEGMENr  PICK  PRIORITY> 

1  <ESCAPE> 

I  <ME5SAGE> 

I  <APPLICAT10N  DATA> 

I  <DRAWINGSET> 

I  <DRAWING  PLUS  CONTROL  SET> 
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Annex  Q  Formal  Grammar  of  the  QKSM  Category 

<to  b«  addad-ttiis  vvOt  b«  a  aubaat  of  Anrwx  F> 

Annex  H 

H.1  The  mapping  of  GKS  functlona  to  COM  olemonts 

Tha  tabfa  baiow  shows  a  mapping  batwaan  tha  GKS  functions  and  CGM  atamants.  Tha  alamants  ara  thosa 
containad  in  tha  CGM  as  axtandad  by  this  addandum. 

Tabla  XX  Tha  Mapping  batwaan  GKS  functions  and  COM  alamants. 


GKS  Function 
OPBI WORKSTAHON 


CLOSE  WORKSTATION 
ACTIVATE  WORKSTATION 


DEACTIVATE  WORKSTATION 
CLEAR  WORKSTATKDN 


REDRAW  ALL  SEGS  ON  WORKSTATION 


UPDATE  WORKSTATION 
SET  DEFERRAL  STATE 


MESSAGE 

ESCAPE 

POLYlIf^ 

POLYMaHKER 
TEXT 
RLL  AREA 
CELL  ARRAY 
GDP 

SET  POLYLINE  INDEX 
SETLINETYPE 

SET  UNEWIDTH  SCALE  FACTOR 

SET  POLYLINE  COLOUR  WOEX 

SET  POLYMARKER  INDEX 

SET  MARKER  TYPE 

SET  MARKER  SIZE  SCALE  FACTOR 

SET  POLYL'ARKER  COLOUR  INDEX 

SET  TEXT  INDEX 

SET  TEXT  FONT  AND  PRECISION 

SET  CHARACTER  EXPANSION  FACTOR 


CGM  Bam  ant 

BEGIN  METAFILE 
Matalila  Daacrtptor 

{act  matalila  catagory} 

BEGM  PICTURE 
BEGIN  PICTURE  BODY 
END  PICTURE 
B1DMETAFI.E 
Attributa  Sattings 
CUP  RECTANGLE 
Enabla  Output  to  MatafBa 
Diaafaia  Ou^wt  to  Matalila 
MAKE  PtCTURE  CURRBIT 
PREPARE  VIEW  SURFACE 
DELETE  Aa  SEGMenS 
MAKE  PICTURE  CURReiT 
PREPARE  VIEW  SURFACE 
RB)RAW  ALL  SEGMefTS 
UPDATE 

DEFERRAL  MODE 

IMPLICIT  SEGMerr  REGBIERATION  MODE 
(BN1G  and  BNIL  m^  to  BNI) 

{Mapa  to  BNIG  on  intarpratation) 
MESSAGE 
ESCAPE 

POLYLINE 

POLYMARKER 

TEXT 

POLYGON 

CELL  ARRAY 

GDP 

UNE  BUNDLE  INDEX 

UNETYPE 

UNE  WIDTH 

LINE  COLOUR 

MARKER  BUNDLE  INDEX 

MARKER  TYPE 

MARKER  SIZE 

MARKER  COLOUR 

TEXT  BUNDLE  INDEX 

TEXT  FONT  INDEX 

TEXT  PRECISION 

CHARACTER  EXPANSION  FACTOR 


I 
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SET  CHARACTER  SPACING 
SET  TEXT  COLOUR  INDEX 
SET  CHARACTER  HEIGHT 
SET  CHARACTBl  UP  VECTOR 
SET  TEXT  PATHTEXT  PATH 
SET  TEXT  AUGNMENT 
SET  FILL  AREA  INDEX 
SET  FILL  AREA  INTERIOR  STYLE 
SET  FILL  AREA  STYLE  INDEX 

SET  FILL  AREA  COLOUR  INDEX 
SET  PATTERN  SIZE 
SET  PATTHV4  RB^HIBICE  POMT 
SET  ASPECT  SOURCE  FLAGS 
SET  PICK  IDemRER 
SET  POLYLME  REPRESENTATION 
SET  TEXT  REPRESENTATION 
SET  FU.  AREA  REPRESSTTATION 
SET  PATTERN  REPRESBVTAT10N 
SET  COLOUR  REPRESBITATION 


COPY  SEGMeiT  TO  WORKSTATION 

INSERT  SEGMeiT 

SET  SEGEMeR*  TRANSFORMATION 

SET  VISIBILITY 

SET  HIGHLIGHTING 

SET  SEGBOIT  PRIORITY 

SETDETECTABIUTY 

WRITE  REM  TO  GKSM 


CHARACTER  SPACING 
TEXT  COLOUR 
CHARACTBl  HEIGHT 
CHARACTER  ORIBITATION 

TEXTAUGNMBIT 
RLL  BUNDLE  INDEX 
INTERIOR  STYLE 
HATCH  MDEX 
PATTERN  MDEX 
RLL  COLOUR 
PATTERN  SIZE 
RLL  RB:5^CE  POINT 
ASPECT  SOURCE  FLAGS 
PICK  IDBRIRST 
LINE  RB>RESe^A'nON 
TEXT  HB»RESBITATTON 
FILL  RB>RESENTAT10N 
PATrBV4  TABLE 
COLOUR  TABLE 

as  ouirant  CGM  Armsx  E 


CLIP  RECTANGLE 
VOCEXTBfT 
DEVICE  VIEWPORT 

BEGMSEGMBTT 

B«>SEGMB«T 

ReiAKESEGMOIT 

DB-ETESEOMBn* 

DELETE  SEGMB4T 
BEGIN  SEGMerr 
pftmlliva  and  atWbutss 
B4DSEGMBTT 
COPYSEGMBTT 
COPYSEGMBfT 
SEGMBIT  TRANSFORM 
SEGMENT  VISIBILITY 
SEGMBTT  HIGHUGHTING 
SEGMENT  DISPLAY  PRIORITY 
SEGMB^T  PICK  PRIORITY 
SEGMBVT  DETECTABILRY 

APPLICATION  DATA 


SETWMDOW 
SET  VIEWPORT 

SET  VIEWPORT  »4PUT  PRKDRRY 
SELECT  NORMALIZATION  TTTANSFORMAT10N 
SET  CUPPMG  INDICATOR 
SET  WORKSTATION  WINDOW 
SET  WORKSTATION  VIEWPORT 

CREATE  SEGMBfT 
CLOSE  SEGMBTT 
RB4AME  SEGMENT 
0B.ETESEGMe4T 

DELETE  SEGMen*  FROM  WORKSTATION 
ASSOCIATE  SEGAENT  WITH  WORKSTATION 


On  interpralation  tha  rsvarsa  mapping  win  occur  with  itam  typas  baing  ratumad  to  fha  GKS  application  as 
indicatad  in  Annax  E  of  this  addaridum. 
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Add  th«  foUowing  to  tho  ond  of  sub-clauM  5.3: 

3/8  for  Sogmont  Control  Elomonts  and  3/B  for  Sagmant  Attributa  Elamants 
Pag0l1 


Mti  tha  following  to  tabla  1 : 


opooda 

Tbit  coding 

BEGM  SECMB^fT  opooda 

30 

20 

BIO  SeSMen*  opooda 

30 

2/6 

KiO’AFLE  CATEGORY  opooda 

3n 

30 

MAXMUM  VDC  EXTBfT  opooda 

3n 

3/1 

SEGMB^T  PRIORfTY  EXTB^  opooda 

3/1 

3/2 

DEVICE  VIEWPORT  opooda 

30 

20 

DEVICE  VT>ORT  SPEC.  MODE  opooda 

30 

2/7 

DEVICE  VIEWPORT  MAPPING  opooda 

30 

20 

DB=BIRAL  MODE  opooda 

30 

20 

MAKE  PICTURE  CURRENT  opooda 

30 

2/10 

PRB>ARE  VIEW  SURFACE  opooda 

30 

2/11 

UPDATE  opooda 

30 

2712 

MOOff^  FONT  UST  opooda 

30 

2/13 

MOOTY  CHARACTBR  SET  LIST  opooda 

30 

2/14 

BEGM  FIGURE  opooda 

30 

2/15 

END  FIGURE  opooda 

30 

30 

NEW  REGION  opooda 

30 

3/1 

MPUCrr  HXjE  VISIBIUTY  opooda 

30 

30 

SAVE  PRMfTIVE  ATTRIBinES  opooda 

30 

30 

RESTORE  PRIMITIVE  ATTRBUrES  op. 

30 

3/4 

DBJETE  ATTRBUTE  SET  opooda 

30 

30 

CIRCULAR  ARC  CBITRE  BACKW  op. 

3/4 

20 

PIXEL  ARRAY  opooda 

3/4 

20 

UNE  REPRESeiTATION  opooda 

30 

20 

MARKBI  RB>RESBITATION  opooda 

30 

20 

TEXT  REPRESBTTATION  opooda 

30 

3/12 

FILL  REPRESENTATION  opooda 

30 

2/13 

EDGE  RB>RESeiTAT10N  opooda 

30 

2/14 

PICK  CeniRER  opooda 

30 

30 

ORAWMG  MODE  opooda 

30 

30 

REOPB4  SEGMBIT  opooda 

30 

20 

COPY  SEGMENT  opooda 

30 

2/1 

DB-ETE  SEGMENT  opooda 

30 

20 

OBETE  ALL  SEGMENTS  opooda 

30 

2/3 

RBIAME  SEGMBIT  opooda 

30 

2/4 

RB)RAW  ALL  SEGMBITS  opooda 

30 

2/5 

MPuciT  sEGMerr  reg.  mode 

30 

2/6 

fMBVTANCE  FLTBI  opcode 

30 

2/7 

SEGMENT  TRANSFORM  opooda 

30 

20 

SEGMBTT  VISBIUTY  opooda 

30 

2/1 

SEGMBIT  HIGHLIGHTING  opooda 

30 

20 

SEGMENT  DISPLAY  PRIORfTY  opooda 

30 

2/3 

SEGMENT  DETECTABILITY  opooda 

30 

2/4 

SEGMENT  PICK  PRIORfTY  opooda 

30 

2/5 

8  bit  coding 


« 
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Add  th«  following  sub-daus*  aftar  sub-dausa  6.12: 

6.13  Attribute  Set  Neme  perameters 

Attributa  Sat  Nama  paramatars  ara  codad  as  intagars  (Basic  format)  at  INTEGER  PRECISION. 

6.14  Device  Point  parameters 

Davioa  Point  paramatars  ara  codad  as  intagars  (Basic  format)  at  INTEGER  PRECISION. 

6.15  Segment  Name  parameters 

Sagmant  Nama  paramatars  ara  codad  as  intagars  (Basie  format)  at  INTEGER  PRECISION. 
PagmSI 

Tha  following  form  sutxiausas  8.1.6  and  8.1 .7 

8.1.6  BEGIN  SEGMENT 

<BEGIN-SEGMBTT-opeoda:  3/0  2/S> 

<intagar:  sagmant-idanti1iar> 

8.1.7  END  SEGMENT 
<e40-SEGMENT<opooda:  3A)  2/6> 

Page  36 

Tha  foVowIng  form  sub<fausas  6.2.16  to  6.2.18 

8.2.16  METAnLE  CATEGORY 

<METARLE-CATEGORY-OPCOOE:  3/1  3n> 

<anumaratad:  matafila  catagory> 

<anumaratad:  matafila  catagory>  -  <intagar:  0> 

I  <intagar:  1> 

I  <intagar:  2> 

8.2.17  MAXIMUM  VDC  EXTENT 

<MAXIUMUM  VDC  EXTENT-opooda;  3/1  3/1  > 

<point:first  cornar> 

<point:sacorxJ  comar> 

8.2.18  SEGMENT  PRIORITY  EXTENT 

<SEGMENT  PRIORITY  EXTENT  op-ooda;  3/1  3/2> 

<intagar:  mirrimum-sagmant-priority  valua> 
<intagar3naximum>sagmant-prionty>valua> 

Pag9  40 

Tha  following  form  sub>clausas  8.4.7  to  8.422 

8.4.7  DEVICE  VIEWPORT 

<DEVICE-VIEWPORT-opcoda;  3/3  2/6> 


{ogtn} 

(gtem) 

(cgmaxtl) 
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<d«vic*<pojnt:  first  com«r>  ) 

<d«vic*-po«nt :  sscond  com«r> ) 

8.4.8  DEVICE  VIEWPORT  SPECIFICATION  MODE 


<OEVICE  VIEWPORT  SPECIFlCAnON  MODE  op-cod«:  30  2/7> 
<cnum«r«t«d:vi«wport>sp«ctfieaiion-<jntt> 

<r«al:  metric  scale  factof> 

<anumarated:  vieport-speclficatlorMirnt>  >  <tnteger:0> 

I  <integar:1  > 

I  <integar2> 

NOTE:  Default  not  conaiatant  with  GKS 

8.4.9  DEVICE  VIEWPORT  MAPPING 

<DEVICE  VIEWPORT  MAPPING  op-code:  30  20> 
^enumerated:  isotropy-flag> 

<enumerated:  horizontal-alignment-flag> 

<enumerated:  vertical  aligrvnent-flag> 

<arHimerated:  iaotropy-flag> 

<enumeratod:  horizontal-alignment-flag> 


<arHimaratad:vertjcai-ellgnment-8ag> 


8.4.10  SET  DEFERRAL  MODE 

<SET-DEFERRAL-MOOE-opooda:  30  20> 
<enumerated:  deferral  mode> 
<enumerated:  deferral  mode> 


■  <integer:0> 
I  <inta^r:1> 

■  <intsgef1}> 
I  <intager:1> 
I  <jrrtager2> 
■i  <intager:0> 
I  <lrrtager1> 
I  <inlagaf2> 


•  <integarO> 
|<lrrlegar  1> 
j<inlo^:2> 


{fractn  of  def.dev  vpt} 
(mm  with  scale  factor) 
(physical  dev  units) 


(not  forced) 

(forced) 

(left) 

(centre) 

{right) 

(bottom) 

(centre) 

(top) 


{•«P} 

(bnl) 

(asti) 


8.4.11  MAKE  PICTURE  CURRENT 
<MAKE  PICTURE  CURReR*  op-ooda:  30  2/10> 

8.4.12  PREPARE  VIEW  SURFACE> 


^PREPARE  VIEW  SURFACE  op-code:  30  2/1 1  > 


<enumerated:  force-hard-copy-edvanoe> 
<anumeratad1orce-hard-copy-advance>  > 

1 

<integer:0> 

<integer:1  > 

(force  hardcopy) 
(conditional) 

8.4.13  UPDATE 

<UPDATE-opcode;  30  2/1 2> 

<enumerated:  update-regeneration-flag> 
<enumeratad:  update-regerreratiorr-lla^  « 

I 

<lnteger  0> 
cintager:  1> 

(perform) 

(postpone) 

8.4.14  MODIFY  FONT  LIST 

<MODIFY  FONT  LIST-opcode;  30  2/1 3> 
<integer:  starting-index> 

<font-declaration>4- 

<font'declaration>  ■ 

<s1ring:  name  of  font> 

8.4.15  MODIFY  CHARACTER  SET  LIST 
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-eMODIPr  CHARACTER  SET  UST-opcod«:  3/3  2/1 4> 
<int«gM':  staiting-ind«x> 

<char«ct«r-Mt*d«c(aration>+ 

<d«stgnation  tail  saquanca> 

<charactar>sat-dacl«tfation>  ■  <inta9ar:0> 

I  <intagar:1> 
I  <inta^2> 
I  <intagar;3> 
I  <intagar2> 


8.4.16  BEGIN  FIGURE 
<BEGIN  FIGURE-opooda  3/3  2/1S> 

8.4.17  END  FIGURE 
<B<IO  RGURE-opooda:  3/3  3A)> 

8.4.18  NEW  REGION 
REGION-cpcoda:  3/3  3/1> 

8.4.19  IMPLICIT  EDGE  VISIBILITY 

<iMPUCrT  EDGE  VISIBILITY-opeoda:  3/3  3/2> 
<anufnafatad:  impflctt*adga-v<sibflMy> 

<anumarBtad:  impiicit-adga-viaibility>  >  <intagarfi> 

I  <inlagar:1> 


{94-charactar  G-sat} 
(96-charactar  G-setj 
{m'byta  94-charG-set} 
{m'byta  9S<harG-sot) 
(complata-coda 
charactar  sat}} 


{off} 

{on} 


8.4.20  SAVE  PRIMITIVE  ATTRIBUTES 

KSAVEPRMrnVEATmiBOTES-opooda:  3/3  3/3> 
<intsgar  attributa>aat-naina> 

8.4.21  RESTORE  PRIMITIVE  ATTRIBUTES 

^RESTORE  PRIMITIVE  ATTRIBUTES-opooda:  3AJ  3/4> 
<intagar  attributa-sat>nania> 


8.4.22  DELETE  ATTRIBUTE  SET 

<OB.ETE  ATTRIBUTE  SET-opooba:  3/3  3^> 
<intagar:  attr1buta-sat>nafna> 
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Add  tha  following  dausas  aftar  dauaa  8.5.1 9 

8.5.20  CIRCULAR  ARC  CENTRE  BACKWARDS 

<CIRCUlARARCCermEBACKWAROS-opcoda:  3/4  2/8> 
<polnt:  cantrapoint> 

<VDC:  OX  start> 

<VDC:OY  slait> 

<VOC:  DX*and> 

<VDC:  DY_and> 

<VDC:  radhjs> 

8.5.21  PIXEL  ARRAY 


« 


100 


Pag9S4 

8.6.36 


8.6.37 


<PIXB.-ARRAY-opood«:  3/4  2/9> 
<point  origin-point> 

<kitog«r:nx> 

<int*g«r:ny> 

min-x-rang«> 

<kit«g«r:  max>x-rang«> 

<irrt*g«r:  fiiin-y-rang«> 

<into^:  max>y-f*ng«> 

<tnt*g«n  x-4eal«> 

<intog«n  y-9eal«> 
<ioeai-colour*pf«cMon> 

<d«tauH'CQ(our>pr«ei3iorvin<ficatar> 

<niimb«r-af-bit8> 

<calour-ll«^ 


m  <d«fauH-colour>pr«ciakir>^ndlcator 
I  <numb«r-o(-bits> 

■  <lntog«rl}> 

■  <into^>positiv*> 

.  {as  COM  ClauM  8.5.9) 


Tha  foVoMring  form  sub-datisaa  8.6.36  to  6.6.42 

LINE  REPRESENTATION 

<LME  REPRESeiTATION-apaoda:  3/S  2m> 
<lntagaf ;  Bna-bundla-<ndax> 

<indox:  flrM-typa> 

<iina-widlh-apaefflar> 

<oolouf-apadBaf> 

<inlsgar:  tlrw-bun(6a-indax> 

<indax:  lna-typa> 


<flna-wklttvflp«eifiar> 


<colour*sp«dflar> 


<intagar:  oolour4ndax> 

MARKER  REPRESENTATION 

<MARKER41EPRESeTrATIONK>pcoci«:  3/5  2/9> 

<intsgar:  markar-bundl«-jnd«x> 
dndax:  markar>typ«> 

<indax:  inarkar-typ«> 

<mark«r>9iza*spacifiar> 

<colour>sp«cifiar> 

<intagar:  mark«r*bundla-ind«x>  >  <posKiva  intag«r> 


<tndax:  markar-typa>  >  <int«g«r:  1>  (dot) 

I  <lntag*r:  2>  (plus) 

I  <intagar:  3>  jastarisk) 

I  <trrtagar;  4>  {circia} 

I  <intagar;  5>  {cross} 


j  <intagar:  nagativa>  {privata  markar  typa) 


<poaWva  lntagar> 
<ititagan  1> 
<intogan2> 
<in(sgar3> 
dniagar  4> 
drrtagar  S> 
drila^:  nagativa> 


(soOd) 

(dash) 

{dot} 

{dash-dot} 
{dash-dot-dot} 
{pdvata  llna  typa} 


<raai:  llna  width-scaia-faetor> 

{H  LINE  WIDTH  SPEC  MODE  is  'scaJa<f} 
<VDC;  llna  width> 

{N  LINE  WIDTH  SPEC  MODE  IS  'atjsoluta'} 
dntagar;  colour  indax> 

{If  COLOUR  SELECTION  MODE  is  Indaxad*} 
<RGB> 

{6  COL  Sa.ECT10N  MODE  IS  ’diracf} 
<non-nagativa  intagor> 


I 
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<mark«r-siz«-sp«cif!«r> 


<colour-sp«cifior> 


<int«g«r:  cokxiMnd«x> 

8.6.38  TEXT  REPRESENTATION 


<raal:  marker  siza-scala-factor> 

MARKER  SIZE  SPEC  MCX)E  ia  -scalarf} 
<VDC:  marker  3ize> 

(H  MARKER-SIZE  SPEC  MODE  IS  'absolute'} 
<tnteger:  colour  index> 

{'if  COLOUR  SB.ECT10N  MODE  IS  Indexed} 
<RGB> 

{H  COLOUR  SELEC  MODE  is  'direct} 
<rKXWiegative  integer> 


<TEXT-REPRESENTATION-opcode:  3/5  3/12> 
<integer  text-bundleH'ndex> 

^integer:  text-font-lndex> 

<enumerated:  text-precision> 

<reai:  charecter-spiMing> 
creal:  axpamior)-factor> 

<colour-specifler> 


<integer:  taxt-bundle-lndex> 
•dntegar.  taxt-font-index> 
<enumeratad:  text-prectsion> 


<real:  expansion-factor> 

8.6.39  FILL  REPRESENTATION 


<poaitive  integer> 

<positlve  lnteger> 

<intager:0>  {string} 

<intsger:1>  {character} 

<lnteger2>  {stroke} 

<nor>-negative  real> 


<rlLL-REPRESENTATION-opoode:  3/6  2/1 3> 
dnteger.  ffll-bundle-lndex> 

<enumerated:  lntefiar-sty(e> 

<index:  hatch^ndex> 

•drrdex:  pattenvirxlex> 

<colour  specifler> 


<integer;fill-bundle-<ndex> 
<enumerated:  interior  style> 


<index:  hatch-index> 


a  <positive  integers 
«  <integer:0>  {hollow 
I  <integer;1  > 

I  <integer2> 

I  <integer'J> 

I  <integer:4> 

I  <integer;negative> 

>  <integer:1  > 

I  <integer2> 
j  <integer;3> 

I  <integer:4> 

I  <integer:S> 

I  <integer*> 

I  <integerTtegative> 


{solid 

{pattern 

{hatch 

{empty 

{private  style} 

{horizontal} 

{vertical} 

{positive  slope} 
{negative  slope) 
{horiz/vertical  cross) 
{positive/neg  cross) 
(private  styles) 


<index;  pattarrvindex>  ■  <positive  ifTteger> 

<coiour  specifler>  -  <integer;colour  index> 

{if  COLOUR  SELECTION  MODE  is  'indexed' 
I  <RGB> 

{if  COLOUR  SB.ECTION  MODE  is  direef 


8.6.40  EDGE  REPRESENTATION 

<EDGE-REPRESENTATION-opcode;  3/6  2/1 4> 
<integer:  edge-bundle-index> 

<indsx:  edge-type> 


« 
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<«dg*<  width-  sp«cif  i«r> 
<colour-sp«cifiar> 

<irttog«r;  •dg«-bundt««ind«x> 
dndex:  •dg*-typ«> 


<«dg*-width-sp«cifi«r> 


<cok>ur-sp«ctfi«r> 


<Jntog«r:  colour-ind«x> 
8.6.41  PICK  ID 


<positive  int«g«r> 
<tnt«g«r;  1> 
<int«g«r:  2> 
<intsger:  3> 
<irrtag«r:  4> 
<intag«r;  5> 
<int»g«r:  n«gativ«> 


{solid} 

(dash) 

{dot) 

{dash-dot) 
{dash-dot-dot) 
(privats  sdga  typa) 


<roal:  sdga-wldth-scala-factor> 

{H  EDGE  WIDIX  SPECI  MtXE  is  ’scalacf} 
<VDC:  sdga  width> 

{H  EDGE  WIDTH  SPEC  MODE  b  'absoluts'} 

<intogsr;  colour-lndax> 

fif  COLOUR  SaECnON  MODE  a  Indsxodl 

<RGB> 

fit  COLOUR  SBECnON  MODE  b  'dbacf) 
<non-nagativa  lntagsr> 


<PICK-ID-opoods:  3/6  3/2> 

<intsgar:  pi^-id> 

8.6.42  DRAWING  MODE 

<0RAW1NG  MOOE-opoods:  3/6  3/3> 

<lntagsfa1fawing-moda> 

<ints^3jrawing-moda>  •  <intsgsr:0> 

I  <intagsr;1> 

1  <intagof2> 

I  <jntsgsr:3> 

I  <intsgsr;4> 

I  <intsgsr:S> 

I  <intsgsr:6> 

I  <intagsr:7> 

I  <intogsr:8> 

I  <intogsr:9> 

I  <intogor:10> 
I  <intsgsr:11> 
I  <intsgsr;12> 
I  <intsgsr:13> 
I  <intogsr:14> 
I  <intsger:15> 

Pag956 


Tha  following  forms  sub-dausas  8.9  and  8.10 

8.9  S«gment  Elements 

8.9.1  REOPEN  SEGMENT 

<REPOPEN-SEGMENT-opooda;  3/8  2AJ 
<intagar:  sagmant-idontifiar> 

8.9.2  COPY  SEGMENT 

<COPY-SEGMENT-opcoda:  3/8  2/1> 
<intagar:  sagmant-kfantifiar* 

<traraformation  matrix> 


{rf-0) 

(tf-sANDd) 

{<r-s/\ND(NOTd)) 

{cf-s) 

{(f -{NOT  a)  AND  d) 
{tf -<4 

{rf-aXORd) 

{(f-sOR(4 

{rf-NOT{sORd)} 

{d’-NOT{sXORd)) 

{(f-NOTd) 

{d’-sOR(NOTd)) 

{(f-NOTs) 

{tf-fNOTs)  ORd) 

{d’-NOT(sANDd)} 

(rf-1) 
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<trans<onnation  matrix> 


<real:a11  > 
<reai:  a21  > 
<raal:  a12  > 
<r^ai:  a22  > 
<^e  :  a1 3  > 
<vdc :  a23  > 


8.9.3  DELETE  SEGMENT 

<OELETE-SEGMBn'-opcoda:  3/8  2/2> 
<in(agar:  sagmant-klantifiar> 


8.9.4  DELETE  ALL  SEGMENTS 
<OB.ETE-ALL-SEGMENTS-opooda:  3/8  2A3> 

8.9. 5  RENAME  SEGMENT 

<RENAME-SEGMBn'-<9peoda:3/8  2/4> 

<jntagar  old-sagmant-idantiflao 
•dntagar:  naw-aagnMnt-ldantlflar> 

8.9.6  REDRAW  ALL  SEGMENTS 
<REORAW*ALL-SEGMBfTS-opoocla:  3/8  2/S> 

8.9.7  IMPUCrr  SEGMENT  REGENERATION  MODE 

<IMPLICfT-SEGMENr-REGENERAT10NH]pcoda:  3/82/6> 
<0numaratad:  impHdt«aaginant-<aganafatiQixnoda> 
<anu(n«ratad:  im^ldf-9tg-r0g0O-fribd0>  m  <Magar.'0> 

I  <intagar:1> 


8.9.8  INHERITANCE  FILTER 

<INHERrTANCE-FILTER-opcoda:  3/8  2/7> 

<anum«ratad:  fiHar-9«<«ction>attributa^asignator> 
<anumaratad;  aatting> 

<8nuniaratad:  finar-sal«c-att-dasignator>  >  <intagar:0> 

I  <inta9ar;1  > 
I  <integer2> 
I  <intagar:3> 
I  <intagar:4> 
I  <:intagar:5> 
I  <intager:6> 
I  <integer;7> 
I  <intag9r:8> 
I  <tntogar:9> 

<anuniarated:  satting>  >  <statajist> 

I  <intagar:1  >  (aagmant) 


{supprassad} 

(aHowad) 


{linas  attributas} 
(mari^ar  attrubute) 
(taxt  attributas} 
{character  attributes} 
{fill  attributes) 

{edge  attributes) 
{pattern  attributes) 
{clip  control) 

{output  control) 

{all) 


8.10  Segment  Attribute  Elements 


8.10.1  SEGMENT  TRANSFORM 

<SEGMENT-TnANSFORM-opcode:  3/9  2/0> 

<intager:  sagment-idontifler> 

<transforTnation  matrix> 

<transformation  mafrix>  »  <real:  at  1  > 
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I  <r«al:  a21  > 

I  <rMl:a12> 
\  <rMl:a22> 

I  <vdc:a13> 
I  <vdc  :  a23  > 


8.10.2  SEGMENT  VISIBILITY 


<SEGMENT-VISIBILrTY-opGod«:  3/0  2/1  > 

<int«g«r:  s«gm«nt>id«nti(i«r> 

<«num«rat«d;  aagmant-v<sibilHy> 

<anunMratad:  saginant>viaMlit^  >  <intagar;  0> 

I  <intagar;  1> 


8.10.3  SEGMENT  HIGHLIGHTING 


<SEGMENT-HIGHUGHT1NG-opeoda:  3/9  2/2> 
dntagar:  sagfnant*ld«ntffi«r> 

<anuniara(ad:  sagfnant-Nghllghting> 

<anumarat8d:  aagmant-h>ghBghtlng>  >  <intagar  0> 

I  <intagar  1> 

8.10.4  SEGMENT  DISPLAY  PRIORITY 


<SEGMENT-PRIORrTY-opooda:  3/0  2/3> 

<intagar:  aagfnant*ldan<Mar> 

<ititagar:  aagmant«d[aplay-priority> 

<intag«r  aagmant<diaptay-priorit^  >  <positlva  in(agai> 

8.10.6  SEGMENT  DETECTABILITY 


<SEGMesrT-OETECTABILrTY<opooda:  3/0  2/4> 

<lntag«r.  aagm«nt-klantlfiaT> 

<anuniaratadaagfn«nt-clat«ctaMlty>  *  <lntagan  0> 

I  <intagar:  1> 


8.10.6  SEGMENT  PICK  PRIORITY 

<SEGMENT-PICK.PRIORrrY-opooda:  3/9  2/5> 

<intag«r:  a«gfnant*<d«ntiflar> 

<intag«r  p<ck-prionty> 

<in(agar:  pick  priority  -  <positjva  intagao 


{visiWa} 

{lnvisib«a) 


{normal} 

{NgNightad} 


undataetabia} 

{datactabla} 
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Add  ttw  foNowing  to  teblo  1 ; 


ASN 

SI  at  intagar 

BASN 

ASNR  {-2”(15) 

pracision  (ip) 

to 

2**(15)-1} 

DP 

OJ) 

BOP 

{-2*BI) 

DPR{-2**(15) 

to 

2**(15)-1) 

SN 

SI  at  intagar 

BSN 

SNR  {-2~(15) 

pradaion  (Ip) 

to 

2**(1S).1) 

VSP 

(R.fl) 

or 

BVSP  (-2*BF^ 

VSPR-{RR} 

(l.l) 

or 

BVSP  {-2*81} 

VSPR-{IR} 

DP 

BVSP(.60P} 

VSPR-(DPfq 

Pag*  17 

Add  th«  toliawing  to  item  10): 
h)  riMlrie  aeate  factor 

Pagaia 

Add  tha  foKowino  to  Tabte  2: 

8  Sagmant  Control  alamante 

9  Sagmant  Attiibuta  atemante 


Paga20 

Add  tha  following  to  tabla  3: 

BEGMSEGMBn’  6  SN  BSN  SNR  n/s 

etOSEGMENT  7  n/a  0  n^a  rVa 

Coda  Dascnption 

6  SEGIN  SEGMENT :  has  1  paramatar; 

:  (sagmant  nama)  sagmant  idantifiar 

7  END  SEGM0fr :  has  no  paramatars 


Pag*  21 

Add  tha  following  to  tabla  4; 


METARLE  CATEGORY 

16 

E 

BE 

ER 

0 

MAXIMUM  VOC  EXTENT 

17 

2P 

2BP 

VDCR 

VDC  EXTENT 

SEG  PRIORITY  EXTENT 

18 

21 

2B) 

IR 

0,  32767 

(Note:  Paramatar  ranga  ER  Is  not  assignad  to  data  typa  'anumaratad* 
in  tabla  1 .  although  usad  in  tabla  8  for  INTERIOR  STYLE.) 

Coda  Oascription 


( 
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1 6  METARLE  CATEGORY:  has  1  paramstsr: 

Pi :  (snumaratsd)  category:  ths  following  values  ars  standardized: 
0  cgm 

1  gksm 

2  cgmextl 

17  MAXIMUM  VOC  EXreiT:  has  2  parameters: 

Pi :  (point)  first  point 

P2:  (point)  second  point 

18  SEGMBIT  PRiORfTY  EXTENT:  has  2  parameters: 

Pi :  (integer)  minimum  segment  priority  value 

P2:  (into^)  maximum  segment  priority  value 
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Add  the  folowing  to  table  6: 


DEVICE  VIEWPORT 

DEVICE  VIEWPORT 

7 

2VSP 

2BVSP 

VSPR 

see  below 

SPECIFICATION  MODE 

8 

Efl 

BEiSR 

{0.1 

RR 

0.- 

DEVICE  VIEWPORT 
MAPPING 

9 

3E 

3BE 

{0.1} 

1 

{0.1  i) 

0 

{0.1  i) 

0 

DEFERRAL  MODE 

10 

E 

BE 

{0.1  i) 

0 

MAKE  PICTURE  CURRB4T 

11 

rWi 

0 

nfa 

n/a 

PREPARE  VIEW  SURFACE 

12 

E 

BE 

{0.1} 

n/a 

UPDATE 

13 

E 

BE 

{0.1} 

n/a 

MODIFY  FONT  LIST 

14 

IXnS 

BIX-hiBS 

+IXRSR 

rVa 

MODIFY  CHAR  SET  LIST 

IS 

IX. 

BIX+ 

4ixa 

n/a 

n(E.S) 

n(BEe8S) 

{0..4I.SR 

BEGM  FIGURE 

16 

rVa 

0 

nfa 

(Va 

BiD  FIGURE 

17 

rVa 

0 

n/a 

iVa 

NEW  REGION 

18 

rVa 

0 

nfa 

n/a 

IMPLICIT  EDGE  VISIBILITY 

19 

E 

BE 

{0.1} 

0 

SAVE  PRIMITIVE  ATTS 

20 

ASN 

BASN 

ASNR 

n/a 

RESTORE  PRIMITIVE  ATTS 
DSLETE  ATTRBUTE  SET 

21 

22’** 

ASN 

BASN 

ASNR 

n/a 

Code  Description 

7  DEVICE  VIEWPORT:  has  2  parameters: 

P1 :  (device  point)  first  point 

P2:  (device  point)  secr^  point 

The  default  DEVICE  VIEWPORT  is  the  entire  device  view  surface  if  the  latter  is  rectangular,  or  the 
largest  rectangular  subset  having  the  desired  aspect  ratio,  if  the  view  surface  is  not  rectangular. 
The  default  is  set  so  that  the  Urst  point'  is  below  and  to  the  left  of  the  'second  point’  as  seen  by  the 
viewer. 

8  DEVICE  VIEWPORT  SPECIFICATION  MODE:  has  2  parameters: 

Pi :  (enumerated)  viewport  specification  units:  valid  values  are: 

0  fraction  of  default  device  viewport 

1  millimetres  with  scale  factor 

2  physical  device  units 

P2:  (reai)  metric  scale  factor,  ignored  if  PI  >0  or  PI  >2 

9  DEVICE  VIEWPORT  MAPPING:  has  3  parameters: 

Pi :  (enumerated)  isotropy  flag:  valid  values  are: 

0  not  forced 

1  forced 

P2:  (erxjmerated)  horizontal  alignment  flag:  valid  values  are: 


« 
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0  Isft 

1  centre 

2  right 

P3:  (enumerated)  vertical  alignmeni  flag:  valid  values  are: 

0  bottom 

1  centre 

2  top 

10  OB^ERRAL  MODE:  has  1  parameter: 

PI :  (enumerated)  deferral  mode:  vaBd  values  are: 

0  asti 

1  bni 

2  aaap 

11  MAKE  PICTURE  CURRBrr:  has  no  parameters 

12  PREPARE  VIEW  SURFACE:  has  1  paramatar: 

PI :  (enumerated)  force  hardcopy  advanoa:  valid  values  are 
0  force  hardcopy 

1  conditional 

13  UPDATE:  has  1  parameter: 

PI :  (enumerated)  update  regeneration  flag:  valid  values  are: 

0  perform 

1  postpone 

14  MODIFY  FOKT  LIST:  has  a  variable  parameter  IsC 
PI :  (index)  starling  font  Rat  index 

P2-Pn:  n  font  names  (strings) 

15  MODIFY  CHARACTER  SET  LIST:  has  a  variable  pmmeterRst 
PI :  (Index)  starting  character  set  1st  Index 

For  each  of  the  variable  number  of  parameter  pairs: 

PI:  (enumerated)  CHARACTER  SET  TYPE:  vafid  values  are: 

0  94*character  G-set 

1  86-character  Gset 

2  84-character  muitlbyte  G-set 

3  86-character  muitlbyte  O-eet 

4  complete  code 
negative  for  private  use 

P(i4>1):  (string)  desigrwtion  sequence  tail;  see  part  1.  5.3.13. 

16  BEGIN  FIGURE:  has  no  parameters 

1 7  END  RGURE:  has  no  parameters 

1 8  NEW  REGION:  has  rx)  parameters 

18  IMPLICIT  EDGE  VISIBILRY;  has  1  parameter: 

Pi :  (enumerated)  implicit  edge  visibility:  valid  values  are: 

0  off 

1  on 

20  SAVE  PRIMITIVE  ATTRIBUTES:  has  1  parameter: 

Pi :  (attribute  set  name)  attribute  set  name 

21  RESTORE  PRIMITIVE  ATTRIBUTES:  has  1  parameter: 

P1 :  (attribute  set  name)  attribute  sat  name 

22  DB-ETE  ATTRIBUTE  SET:  has  1  parameter: 

PI :  (attribute  set  name)  attribute  set  name 


« 
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Add  th«  following  to  tablo  7: 


CIRCULAR  ARC  CBfTRE 
BACKWARDS 

20 

P.4VDC. 

BP446VDC4- 

VDCR.VDCR.  n/a 

PIXH.  ARRAY 

21 

VX 

P.6I. 

BVDC 

BP488l-«> 

++VDCR 

VDCR,IR.  n/a 

21, 

CL  ST 

2Bt4> 

nBCO 

■flR. 

COR 

Cod*  Doscription 

20  CIRCULAR  ARC  CENTRE  BACKWARDS:  Nm  6  pwamotws: 
Pi :  (point)  contra  of  drdo 

P2:  (vdc)  dolto  X  for  atart  voctor 
P3:  (vdc)  dolto  Y  for  start  voctor 
P4:  (vdc)  dolta  X  for  orxi  voctor 
P5:  (vdc)  dolta  Y  for  and  voctor 
P6:  (vdc)  radiua  of  drdo 

21  PIXEL  ARRAY:  haa  1 0  paramotors: 

Pi  :  (point)  origin  point 

P2 :  (intogw)  nx 
P3 :  (intogor)  ny 

P4 :  (Jtitagat)  rriinimum  of  valid  x-rango 
PS :  (intogor)  maximum  of  vaM  x<rango 
P6  :  (intogor)  minimum  of  valid  y-ranga 
P7 :  (intogor)  maximum  of  vaM  y-ranga 
P8  :  (intogor)  x  ocaio 
PO  :  (Intogor)  y  ocaio 

PIO:  (ool^  Rd)  array  of  colour  spodfiors 
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Add  tho  following  to  tablo  8: 


UNE  REPRESefTARON 

36 

2IX 

2BIX-t> 

+IXRIXR, 

n/a 

(VDC  or 

(BVDC  or 

++VOCRor 

R).CO 

BR)4BC0 

++RRCOR 

MARKER  RBRESeiTATTON 

37 

2IX 

2BIX4- 

+IXR.IXR, 

n/a 

(VDC  or 

(BVDC  or 

+.t.VDCRor 

R).CO 

BR)4BC0 

++RR,COR 

TEXT  REPRESBfTATKIN 

38 

2IX 

2BIX-^ 

♦IXR, 

n/a 

E. 

BEr- 

{0,1.2). 

2R.CO 

2BR-»eco 

RR.COR 

FIX  REPRESeiTATiON 

39 

IX, 

BIX-i-' 

+IXR, 

n/a 

E.CO, 

BE-fBCOi- 

{0..4},COR. 

2IX 

2BIX 

IXR.+IXR 

EDGE  REPRESeiTATION 

40 

2IX. 

2SIX-^ 

♦IXR.IXR. 

n/a 

(VDC  or 

(BVDC  or 

♦+VDCRor 

R),CO 

BR)48C0 

♦RR.COR 

PICK  IDefTlRB^ 

41 

1 

Bl 

IR 

n/a 

DRAWING  MODE 

42 

1 

Bt 

■m4R 

3 

Coda  Doscription 

36  LINE  REPRESENTATION:  has  4  paramotors: 

Pi :  (iftoox)  lino  burtolo  indox 

P2:  (indox)  lino  typo:  tho  fdlowing  valuos  aro  standardized: 

1  solid 

2  dash 

3  dot 

4  dash-dot 
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S  dashslot-dot 
n*g«iiv*  for  private  usa 

P3:  (vdo  or  raai)  absolute  lina  width  or  llna  width  acala  factor 

P4:  (ooiour)  Hna  colour  its  form  dapands  on  CCXOUR  SELECTION  MODE. 

37  MARKS)  RB>RESefrATION:  has  4  paramaters: 

PI :  (Max)  marfcar  bundia  Max 

P2:  (Max)  maritar  typa:  tha  following  vaiuos  ara  standardizad: 

1  dot 

2  plus 

3  asterisk 

4  drda 

5  cross 
nagativa  for  private  usa 

P3:  (vdc  or  raal)  absolute  markar  width  or  msrkar  size  scala  factor 

P4:  (ooiour)  markar  ooiour  Its  form  dapands  on  COLOUR  SB.ECT10N  MODE. 

38  TEXTREPRESefTATIONrhasepartenaters: 

PI :  (Max)  text  bunda  Max 

P2:  (Max)  text  font  Max 

P3:  (anumaratad)  text  pradsion:  valid  vaiuas  ara: 

0  string 

1  eharaetar 

2  Stroks 

P4:  (raai)  eharaetar  spadng 

PS:  (raai)  eharaetar  axpandon  factor 

P6:  (ookMii)  text  odour;  Its  form  dapands  on  COLOUR  SB.ECTION  MODE 

30  FILL  REPRESENTATION:  has  5  paramaters: 

Pi :  (Max)  fit  araa  bundls 

P2:  (Max)  interior  styia:  valid  vaiuas  ara: 

P3:  (Max)  hatch  Max:  tha  following  vaiuas  ara  standardizad: 

1  IMzontal 

2  vartical 

3  positiva  slops 

4  nagativa  stops 

5  combinad  varticaf  arto  horizontal  slant 

6  oombinad  laft  atxf  right  slant 
nagativa  for  private  usa 

P4:  (indax)  paitsm  Max 

PS:  (odour)  M  odour  Its  form  dapands  on  COLOUR  SELECTION  MODE 

40  EDGE  REPRESENTATION:  has  4  paramaters: 

P1 :  (Max)  adga  burxlla  Max 

P2:  (Max)  adga  typa:  tha  following  vaiuas  ara  standardized: 

1  solid 

2  dash 

3  dot 

4  dash-dot 

5  dash-dot-dot 
nagativa  for  private  usa 

P3:  (vdc  or  raai)  absofuta  adga  width  or  lina  width  seals  factor 

P4:  (odour)  ad^  odour:  Its  form  daparxfs  on  COLOUR  SELECTION  MODE. 

41  PICK  lOENTIRER:  has  1  paramater: 

PI :  (intagar)  pick  idsntifiar 

42  DRAWING  MODE;  has  1  paramater; 

PI :  (intagar)  drawing  mods:  vaHd  vaiuas  ara: 

0  (f-0 

1  cf-aANDd 

2  (f-sAND(NOTd) 

3  (f^s 

4  d'HNOTs)ANDd 
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5  d*^ 

6  (f^XORd 

7  OR  d 

8  d’J«DT(sORd) 

9  cf-NOT  (a  XOR  d) 

10  (f-NOTd 

11  <f-8  0R(N0Td) 

12  (f-NOTs 

13  <r-<NOTs)ORd 

14  (f-MOTCsANOd) 

15  <f-1 

(d*  m  raaulting  dastinalion  bit  vaiua. 
d  >  original  Salination  bit  vaiua, 
a  ■  original  aourca  bit  vahia) 


Paga39 


Tha  following  fofma  aub-dauaa  7.10 
7.10  S«giiMnt  Control  Eiomonts 
Tabla  11  -  Encoding  of  aagmant  oonlrol  alamanta 


Elamant 

a 

Param 

Paramatar 

Paramatar 

DafauK 

daaaS 

Id 

Typ« 

Liat 

Loftglh 

Ranga 

REOpetsEGMerr 

1 

SN 

BSN 

SNR 

nfa 

coPYSEGMerr 

2 

SN.4R. 

2VDC 

BSN«48R+ 

2BVDC 

SNR,Ra 

VDCR 

n/a 

DB^TESEGMerr 

3 

SN 

BSN 

SNR 

n/a 

OBJETE  ALL  SEGMENTS 

4 

nte 

0 

nfa 

n/a 

RBIAMESEGMerr 

5 

2SN 

2BSN 

SNR 

n/a 

REDRAW  Aa  SEGMerrS 
IMPUCrr  SEGMENT 

6  rVa 

0 

niA 

n/a 

REGBIERATIONMODE 

7 

E 

BE 

{0.1} 

0 

NHERTTANCEFILTER 

8 

nEE 

(m-l)BE 

{0..9}.{0,1} 

-.1 

Coda  Oaacription 

1  REOPEN  SEGMBfT:  haa  1  paramatar; 

Pi :  (aagmant  nama)  aagmant  idantifiar 

2  COPY  SEGMBfT:  haa  7  paramatara; 

Pi ;  (aagmant  nama)  aagmant  idantifiar 

Tha  ramaining  6  paramatara  ara  componanta  of  a  3x2  matrix  of  tha  form: 

|"?P3P6| 

|P4P5P7| 

whara 

P2:  (raal)  x  acala  oomponant 
P3:  (raal)  x  rotation  componant 
P4;  (raal)  y  rotation  compor>ant 
P5:  (raal)  y  acala  oomponant 
P6:  (vdc)  x  tranalation  componant 
P7:  (raal)  y  tranalation  oomponant 

3  DELETE  SEGMENT;  haa  1  paramatw; 

Pi :  (aagmant  nama)  aagmant  idantifiar 

4  DELETE  ALL  SEGMENTS:  haa  no  paramatara 

5  RENAME  SEGMENT :  haa  2  paramatara: 
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P1 :  (sagmcnt  nam*)  old  sogmont  idontiTwr 
P2:  (aagmant  nam«)  now  sogmont  idontifior 

6  REDRAW  ALL  SEGMENTS:  has  no  paramolors 

7  IMPLICrr  SEGMB^T  REGENERATION  MODE:  has  1  paramotsr: 

PI :  (onumoratod)  impficit  sogmont  rogonoraiion  moda:  valid  valuos  aro: 

0  supprossod 

1  atowod 

8  INHERITANCE  RLTER:  has  up  to  1 1  paramotors,  oorrosponding  to  oach  of  tho  10  inhontanco  filtor 
function  groups  plus  tho  sotting: 

(onumoratod)  fRW  soloction  attributo  dasignator:  valid  valuos  aro: 

0  lino  attributos 

1  marfcor  attributos 

2  toxt  attributos 

3  charactor  attributos 

4  fll  attributos 

5  odgo  attributos 

6  pattom  attributos 

7  cHp  oontrol 

8  output  control 

9  all 

(onumoratod)  sotting:  valid  valuos  aro: 

0  statojlst 

1  sogmont 


Pag*  39 


Tho  following  forms  sub-dauso  7.1 1 

7.11  S«gm«nt  Attr(tiut«  Etoments 


Tablo  12  •  Encoding  of  sogmont  attributo  olomonts 


Elomont 

B 

Param 

Paramotor 

Paramotor 

Default 

Claas9 

Id 

Typa 

List 

Length 

Range 

SEGMBrTTRANSFORM 

1 

SN.4R. 

2VDC 

BSN448R-I- 

2BVDC 

SNRRR. 

VDCR 

n/a,1 ,0,0,1 , 
0.0 

SEGMENT  VISIBILITY 

2 

SN.E 

BSH^BE 

SNR.(0.1) 

n/a,0 

SEGMB^T  HIGHUGHTING 

3 

SN,E 

BSh4BE 

SNR,{0.1) 

n/a,0 

SEG  DISPLAY  PRIORITY 

4 

SN,I 

BSN^BI 

SNRIR 

n/a.soo  below 

SEGMB>(T  DETECTABUTY 

5 

SN.E 

BSNfBE 

SNR,{0.1| 

n/a.O 

SEGMENT  PICK  PRIORITY 

6 

SN.I 

BSN-^BI 

SNR.IR 

n/a,seo  below 

Coda  Dosription 

1  SEGMENT  TRANSFORM:  has  7  paramotors: 

PI :  (sogmont  namo)  sogmont  idWifior 

Tho  romaining  6  paramotors  aro  compononts  of  a  3x2  matrix  of  tho  fonn : 

|P2  P3  P6| 

|P4  P5  P7I 
whoro 

P2:  (roal)  x  scalo  oomporwnt 
P3:  (roal)  x  rotation  componont 
P4;  (roal)  y  rotation  componont 
PS:  (roal)  y  scalo  componont 
P6:  (vdc)  X  translation  componont 
P7:  (vdc)  y  translation  componont 


« 
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2  SEGMB4T  VISIBILITY:  has  2  paramstsrs: 

PI :  (ssgmsnt  name)  segmarrt  idarrtifisf 

P2:  (anumaratad)  visibflity:  valid  valuas  ara: 

0  visibla 

1  invisibla 

3  SEGMENT  HIGHLIGHTING:  has  2  paramatars: 

PI :  (sagmant  nama)  sagmant  IdanMar 

P2:  (amanaratad)  highlighting:  valid  valuas  ara: 

0  nonnal 

1  highUghtad 

4  SEGMBVT  DISPLAY  PRIORITY:  has  2  paramatars: 

PI :  (sagmant  nama)  sagmant  IdantMar 

P2:  (Intagar)  sagmant  d^.ay  priority 

Tba  dateult  of  tha  sagmant  dspiay  priority  Is  aqual  to  tha 

minimum  sagmant  priority  valua  (aaa  sub-dausa  7.3) 

5  SEGMENT  DETECTABILITY:  haa  2  paramatars: 

Pi :  (sagmant  nama)  sagmant  Idanbflar 

P2:  (anumaratad)  datadafaflHy:  valid  vakiaa  ara: 

0  undatactabla 

1  datactabla 

6  SEGMENT  PICK  PRIORITY:  has  2  paramatars: 

P1 :  (sagmant  nama)  sagmant  IdantMlar 

P2:  (intagar)  sagmant  pick  priority 

Tha  dafault  of  tha  sagrnant  (fspl^  priority  b  aqual  to  tha 

minimum  sagmant  priority  valua  (aaa  sufendausa  7.3) 
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Information  Processing  Systems  - 

Computer  Graphics  - 

Metafile  for  the  Storage  and  Transfer 
of  Picture  Description  information 
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Clear  Text  Encoding 
Addendum  1 
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Add  th«  foHowring  to  th«  ond  of  sub^ua*  S.3.S 
ASN  :u*  <l>  {attribute  sot  nama) 

SN  <l>  (aagmarrt  nama} 

VC  <R>|<b.  {dapandng  on  OEV  VIEWPORT  SPEC  MODE) 

VSPOIMTREC  <VCxSEPxVC> 

VSP  <VSPOWTREC>f<<LEFTPARBixOPTSEPxVSPOfNTRECxOPTSEP> 

<RIGHTPARB4>> 

(COORDINATE  in  vlawport  apadfieation  tpaoa.  Paranthasaa  ara  optionaL  N  thay  aia  usad,  thay 
shall  group  axactly  two  raal  or  Intagar  numbars,  dapanding  on  DEVICE  VIEWPORT 
SPECIFICATION  MODE  Tba  paranthasizad  form  is  intendad  to  aid  raadabWy  of  tha  matefila} 

m  <RxSB>xflxSEPxVDCxSBS<RxSEPxRxSS>xVDC> 

(2*3  raal  barwformatlon  matrix  in  row-major  ardor} 


Paga12 

Add  tha  foUawing  to  tha  and  at  sub-dauaa  5.4.3 


ALL 

HARDCOPY 

CATB30RY 

MAKE 

CONOmONAL 

NEW 

COPY 

PICK 

DELETE 

PIXEL 

DEVICE 

PRS>ARE 

DBPLAY 

RH)RAW 

ORAWMG 

REGION 

FIGURE 

REOPEN 

num 

SAVE 

SURFACE 

FORCE 

UNTTS 

FRACTION 

UPDATE 

VIEW 

Paga  12 

Add  tha  foilowing  to  tha  and  of  sub-clausa  5.4.4 


ATTRIBLrrE(S) 

ATTR 

BACKWARDS 

BACK 

CURRBTT 

CUR 

DEFERRAL 

DEFER 

DETECTABLE 

DET 

DETECTABUTY 

DET 

HIGHLIGHTING 

HIGHLIGHT 

iDerriFiB? 

ID 

wPLicrr 

IMPL 

INHERTTANCE 

INH 

MAPPING 

MAP 

MLLIMETER 

M4 

MODIFY 

MOD 

PHYSICAL 

PHY 

PRIMmVE 

PRIM 

PRIORnY 

PRI 

REGENERATION 

REGEN 

REPRESBVTA7ION 

REP 
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RESTORE  RES 

SEGMB^  SEG 

TRANSFORM  TRANS 

UNDeTECTABLE  UNDET 


Pag*  14 


Add  the  following  to  tho  ond  of  sub-daua*  S.4.5 


BEG»4SEGMe^ 

BEGSEG 

B«)SEGMe^ 

BIDSEG 

METAFLE  CATEGORY 

IWFCATEGORY 

MAXMUMVOC  EXTENT 

MAXVDCEXT 

SEGMerr  PRIORITY  EXTENT 

SEGPRIEXT 

DEVICE  VIEWPORT 

DEVICEVIEWPORT 

DEVICE  VIEWPORT  SPECIFICATION  MODE 

DEVICEViEWPORTlylODE 

DEVICE  VIEWPORT  MAPPfIG 

DEVICEVIEWPORTMAP 

DSeiRALMOOE 

DEFHTMOOE 

MAKE  PICTURE  CURRBTT 

MAKEPICCUR 

PRS>ARE  VIEW  SURFACE 

PREPAREVIEWSURFACE 

UPDATE 

UPDATE 

MODIFY  FONT  LIST 

MODFONTUST 

MODIFY  CHARACTER  SET  LIST 

MODCHARSETTJST 

BEGM  FIGURE 

BEGFIGURE 

BO  FIGURE 

BOFIGURE 

NEW  REGION 

NEWREGION 

IMPLlCrr  BXBE  VISBUTY 

IMPLEDGEVIS 

SAVE  PRiMfTTVE  ATTRIBUTES 

SAVH>RIMATTR 

RESTORE  PRiMfTTVE  ATTRBUTES 

RESPRHMATTR 

DOETE  ATTRBUTE  SET 

DBjsIkAI  1  kSET 

ORCUIAR  ARC  CBITRE  BACKWARDS 

ARCCTRBACK 

PIXB.  ARRAY 

PIXELARRAY 

LINE  REPRESeVTATION 

LINEREP 

MARKER  RE>RESBfTATION 

MARKERREP 

TEXT  REPRESB4TAT10N 

TEXTREP 

Fll  REPRESB^ATION 

FILLREP 

EDGE  REPRESeVTATION 

EDGEREP 

PICK  IDBVnnEfl 

PICKID 

DRAWNGMOOE 

DRAWWGMODE 

REOPBISEGMEVT 

REOPENSEG 

COPYSEGMBfT 

COPYSEG 

DB.ETESEGMBfT 

DELETESEG 

De.ETE  ALL  SEGfCNTS 

OELETEALLSEG 

RBfAMESEGMBrr 

RENAMESEG 

REDRAW  ALL  SEGMENTS 

REDRAWALLSEG 

MPUCfT  SEGMENT  REGENERATION  MODE 

IMPLSEGREGBIMODE 

WHBVTANCE  FILTH! 

INHF1LTER 

SEGMBVT  TRANSFORM 

SEGTRANS 

SEGMBfTVISIB«.rTY 

SEGVIS 

SEGMBIT  HIGHUGKTING 

SEGHIGHLIGHT 

SEGMBfT  DISPLAY  PRIORITY 

SEGDISPLAYPRI 

SEGMBIT  DETECTABIUTY 

SEGDET 

SEGMBfr  PICK  PRIORITY 

SEGPICKPRI 
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<THRM> 


OS^flRALMOOE  DEFBWA30E 

<SOFTSEP> 

<TEnM> 

Not*;  GKS  has  BNIG  and  BNIL  instvad  of  BNI.  In  addition  th*  chos*n  CGI 
dafault  is  not  conaistant  with  GKSI 

MAKEPKmjREGURRB^  ;:-i  MAKEPICCUR 

<TEnM> 

PREPARE  VIEW  SURFACE  PREPAREVIEWSURFACE 

<SOFTSSb. 

<FORC&iAROCOPY1CONDmONAL> 

<TERM> 


UPDATE  UPDATE 

<SOFTSEP> 

<PERF0RM)P06TP0NE> 

<TERM> 

MODIFY  FONT  LIST  ;>  MOOFONTUST 

<SOFTSEP> 

<ISTARTmDEX>  {posHiv*} 

<SEP> 

<S:FONTNAME> 

<SEP>  <S.FONTNAME>* 

<TERK^ 

MODIFY  CHARACTER  SET  LIST  MODCHARSETUST 

<SOFTSEP> 

<I:STAHT1NDEX>  (positiv*) 
<CHARSETDESIGNAT0R>4. 
<TERM> 

CHARSETDESIGNATOR  <SEP> 

<STD94| 

STD96j 

STD94AWLTTBYTE1 

STD96MULT1BYTEj 

COMPLETECODE> 

«OPTSEP>|<HARDSEP» 

<S:TAIL> 

BEGIN  FIGURE  BEGFIGURE  <TERM> 

BID  FIGURE  0IDRGURE  <TERM> 

NEW  REGION  :>  NEWREGION  <TERM> 

IMPLICIT  EDGE  VISIBILITY  IMPLEDGEVIS 

<SOFTSEP> 

<OFF10N> 

<TERM> 

SAVE  PRIMITIVE  ATTRIBUTES  SAVEPRIMATTR 

<SOFTSEP> 

<ASN.ATTRIBUTESETNAME> 

<TERM> 

RESTORE  PRIMITIVE  ATTS  RESPRIMATTR 

<SOFTSEP> 

<ASN:ATTRIBUTESETNAME> 
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Add  th*  following  to  tho  end  of  sub-dauM  6^ 

BEGIN  SEGMBTT  BEGSEG 

<SOFTSEP> 

<l:SEGIO> 

<TERM> 

BIOSEGMBfT  BIDSEG 

<TERM> 


Pag*  17 

Add  tha  following  to  ttM  and  of  aut>clauaa  6.3 

METAFLECATEGOnV  MFCATEGORY 

<SOFTSEP> 
<CGM|GKSM|CGM0CT1  > 
<JEPM> 

MAXMUMVDCEXre^  MAXVOCEXT 

<SOFTSEP> 

<P-.nRSTCORNER> 

<SEP> 

<P:SECONDCORNB^ 

<TERM> 

SEGMefTPRlORrTYEXTBfr  SEGPRIEXT 

<SOFTSEF»> 

<IMINSEGPRI> 

<SEP> 

<IMAXSEGPni> 

<TEFM> 


Paga19 

Add  tha  following  to  tha  and  of  aub-dauaa  6.5 

DEVICE  VIEWPORT  OEVICEVIEWPORT 

<SOFTSEP> 

<VSPJ=IRSTCORNER> 

<SEP> 

<VSPSECClNDCORNER> 

<TERM> 

DEVICE  VIEWPORT  SPEC  MODE  DEVICEVIEWPORTMODE 

<sSOFTSEP> 

<FRAC'nON|MM|PHYDEVICEUNrrs> 

<SEP> 

<R:SCALEFACTOR> 

<TERM> 

Nota:  Tha  chosan  CGI  default  is  not  consistent  with  GKS 

DEVICE  VIEWPORT  MAPPING  DEVICEVIEWPORTMAP 

<SOfTSEP> 

<NOTFORCED|FORCED> 

<SEP> 

<1JEF71CTR|RIGHT> 

<SEP> 

<BOTTOM|CTR|TOP> 
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<TEHM> 


OeLETEArmBUTESET  Da^TEATTRSET 

<SOFTSeP> 

<ASNAT7RIBLrreSE7NAME> 

<TERM> 
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Add  th*  folowHng  to  th«  and  of  sub-ctauM  6.6 


CIRCULAR  ARC  Ca^EBACKW  ARCCTRBACK 

<CTRARCSPEC> 

PDCB.  ARRAY  PIXBARRAY 

<SOFTSEP> 
<PORIGIN  POINT> 
<SEP> 

<I:NX> 

<SEP> 

<I:NY> 

<SEP> 

<iMIN_X  RANGE> 
<SEP> 

<IMAX_X  RANGE> 
<SEP> 

<IMINjr  RANGE> 
<SEP> 

<I:MAX  Y  RANGE> 
<SEP> 
<IJ<_SCALE> 
<SEP> 

<fcY_SCAUE> 

<SEP> 

<LOCLCOLRSPEC> 

<CELjLROW>* 

<TERM> 

Pagm28 


Add  tho  foMowing  to  tho  ond  of  sub-dauM  6.7 


LINE  REPRESefTATION  LINEREP 

<SOFTSEP> 

<lfiUNDLEINDEX>  (poaitiva} 
<SEP> 

<cl:LINETYPE> 

(lasofid.  2>dash 
Sadot.  4>dash-dot 
S^ash-dot-dot 
<0  impfaniant'n  dapandant} 

<SEP> 

<V1,INEWIDTH>  (non-nagativa) 
<SEP> 

<K.1.INECOLR> 

<TERM> 


MARKER  REPRESENTATION 


MARKERREP 

<SOFTSEP> 

<l£UNOLEINDEX>  {positivaf 
<SEP> 

<IMARKERTYPE> 


« 
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TEXT  RB»RESB^ATK:)N 


RU  RB’RESBfTATION 


EDGE  REPRES^AHON 


PICK  lOENTlRER 


2-pius 

S-astorisk.  4acirei« 
S^oss  (x) 

<0  itnplamanf  n  dapandant) 

<SEP> 

<VMARKERSIZE>  (norwwgattva) 
<SEP> 

<KMARKERCOLR> 

<TERM> 


TEXTREP 

<SOFTSEP> 

<ISUN0LEiN0EX>  {poaMva} 

<SEP> 

<l:F(>niNDEX>  (poaitiva) 

<SEP> 

<STRMG|CHAR|STROKE> 

<SEP> 

<R:SPACING> 

<SEP> 

<RfACTOR> 

<SEP> 

<K:TEXn:0LR> 

<TERM> 

nLRB> 

<SOFTSEP> 

<lfiUNOLElNDEX>  (poaMva) 

<SEP> 

<HOaOVV|SOL10|PAT1HATCH|B(ff>TY> 

<SEP> 

<liWTCHNOEX> 

(1  >horizontal^avarlical 
3i^x>si1iva  slopa 
4aaiaga1iva  aiopa 
SahorizA^art  croaa 
aiopa  croaa 

<0  bnpiamanL  dapandafTt 

<SEP> 

<I:PAT1NDEX>  {poaitiva) 

<SEP> 

<K;FILLCCXR> 

<TERM> 


EOGEREP 

<SOFTSEP> 

<iSUNO(.EINDEX>  {postth/a} 
<SEP> 

<I:EDGETYPE> 

(tiisolid.  2adaah 
3>dot.  4«dash-dot 
S-daah-dot-dot 
<0  icnpiamant’n  dapandant) 

<SEP> 

<V£0GEW1DTH> 

<SEP> 

<K:EDGECOLR> 

<TERM> 


PICKIO 

<SOFTSEP> 

<l:SEGiD> 

<TERM> 
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ORAWtJGMOOE 


DRAWMGMOOE 

■eSOFTSEP> 

<I.-ORAWMGMOOE> 

(0  (f-O 

1  (f^ANOd 

2  tf-«ANO(NOTd) 

3  <f-« 

4  d’-<NO(Ts)ANOd 

5  tf-d 

6  (fi«XORd 

7  (f-tOfld 

8  <f>MOT(sORd) 

0  <f-440T(sX0Rd) 

10  (f-NOTd 

11  d’i4  0R(N0Td) 

12  (f-NOTs 

13  (f-(NOTs)ORd 

14  (f-NOT(sANOd) 

15  (f-1) 

<TBM> 


Pwg»29 


Th«  following  fonns  sub-dauoo  6.10 
6.10  Encoding  Segment  Control  Elements 
REOPeiSEGMBfT 


COPYSEGMetr 


OB.ETESEGMen’ 

0B.ETE  ALL  SEGMB^ 
RENAME  SEGK^^ 


REDRAW  ALL  SEGMBITS 
IMPLICrr  SEG  REGEN.  MODE 


WHERffANCE  F1LTS1 


REOPBISEQ 

<SOFTSS>> 

<SN:SEGIO> 

<TERM> 

CX)PYSEG 

<SOFTSEP> 

<SN;SEGID> 

<SEP> 

<TM:TRANSMATRIX> 

<TERM> 

OELETESEG 

<SOFTSEP> 

<SN:SEGIO> 

<TERM> 

OELETEALLSEG  <TERM> 

RENAMESEG 

<SOFTSEP> 

<SNKXDSEGIO> 

<SEP> 

<SNt4EWSEGiD> 

•<:TERM> 

REORAWALLSEG  <TER»4> 

IMPLSEGREGENMODE 

<SOfTSEP> 

<SUPPRESSED|ALLOWED> 

<TERM> 


INHFILTER 

<SOFT5EP> 
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<UNEArmi 

MAFIKERATTRI 

TDaATTR} 

CHARATTOI 

HLLATTRI 

EDGEATTRI 

pATArrai 

CUPCONTROLI 

OUTPUTCOrnROLJ 

ALL> 

<SEP> 

<STATBJSTlSEGMefT> 

<TER»A> 


Pag929 

Th«  following  fonma  aub-dauaa  6.1 1 

6.11  Encoding  Sogmont  Attrlbuto  Elomonts 


SEGMBn"mANSFORM 


SEGMErn'VISIBIUTY 


SEGMBir  HIGHUGH11NG 


SEGMENT  OISPIAY  PRIORITY 


SEGMENT  OETECTABIUTY 


SEGMENT  PICK  PRIORITY 


:>  SEGTRAN 

<SOFTSEP> 

<SN:SEGIO> 

<SEP> 

<1M:TRANSMATRIX> 

<TERM> 

:>  SEGVIS 

<SOFTSS»> 

<SN:SEGID> 

<SEP> 

<VIS|INVIS> 

<TERM> 

:>  SEGHIGHLIGHT 
<SOFTSEP> 

<SN:SEGIO> 

<SEP> 

<NORMAL|HIGHUGHTEO> 

<TERM> 

SEGOISPLAYPRI 

<SOFTSEP> 

<SN;SEGIO> 

<SEP> 

<l:DISPLAYPRIORmr> 

<TERM> 

SEGOET> 

<SOFTSEP> 

<SN;SEGID> 

<SEP> 

<UNOET1DeT> 

<TERM> 

SEGPICKPRI 

<SOFTSEP> 

<SN:SEGtO> 

<SEP> 

<l;PICKPRIORITY> 

<TERM> 


« 
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Tht  U.  S.  disapproves  of  Part  1  of  CCM  PDAD  1  (SC24/N19),  with  the 
following  comments.  The  part  1  comments  are  organized  In  3  sections:  The 
first  section  contains  all  comments  except  segmentation  and  formal  grammar; 
The  second  section  contains  segmentations  comments;  And  the  third  section 
contains  formal  grammar  comments. 


Taehnleal  Cflmgnta 

1/Tl)  Global  comment:  How  much  discussion  of  errors  Is  appropriate  for 
the  metafile?  Most  errors  are  a  function  of  the  semantics  of  the 
Interpreter.  Since  CKS  thoroughly  specifies  Its  errors  and 
associated  reactions  to  them,  It  Is  not  necessary  to  repeat  this  In 
this  document. 

1/T2)  Page  2:  Is  there  supposed  to  be  a  'CRSM'  shorthand  for  the  Metafile 
Elements  List? 

1/T3)  DEVICE  VIEWPORT  MAPPING  Is  not  needed  In  the  CKSMO  set,  since  CKS 
only  requires  the  default  of  (Isotropic,  left,  bottom). 

1/T4)  4.12.4.7  and  page  31,  SEGMENT  TRANSFORM:  Needs  to  be  rewritten  to 

reflect  output  of  Valbonne  CGI  that  the  locus  Is  transformed,  not 
just  the  reference  points. 

1/T5)  A  complete  description  of  the  two  mutually  exclusive  ways  of 

mapping  VDC  to  the  device  (using  SCALING  MODE  'metric'  or  using 
DEVICE  VIEWPORT).  3long  with  the  statement  about  using  the  most 
recently  specified  If  both  are  permitted  In  the  metafile  category, 
should  be  In  clause  4,  not  burled  In  Annex  0.  Pictures  are 
critical  here! 

1/T6)  A  section  Is  needed  describing  how  transformation  affects 

primitives  and  attributes.  Page  10,  section  4.12.4.7,  paragraohs  3 
and  4:  These  paragraphs  need  to  be  reworded  to  reflect  the  chan 
to  CGI  regarding  segment  transformations  applying  to  the  locus  o 
graphical  objects,  rather  than  reference  points.  State  the 
appearance  of  CIRCLE.  RECTANGLE,  PI.XEL  ARRAY,  and  RESTRICTED  TEXT 
under  locus  t ransf orma t Ion. 

1/T7)  RENAME  SEGMENT  and  DELFTE  SEGMENT  should  not  be  permitted  In  global 
segments.  These  do  not  appear  to  be  necessary  or  useful. 

1/T8)  COLOUR  SELECTION  MODE,  LINE  WIDTH  SPECIFICATION  MODE.  EDGE 

width  SPECIFICATION  MODE,  and  MARKER  SICE  SPECIFICATION  MODE  should 
be  permitted  In  global  and  local  segments  as  well  as  picture  open 
Even  though  CKS  does  not  maice  use  of  these  functions,  a  non-CKS 
client  could  assemble  a  'library'  of  global  segments  from  different 
metafiles,  to  he  referenced  In  the  pictures  of  the  metafile,  CGI 
has  concluded  that  there  is  no  difficulty  In  mixing  these  modes 
within  a  single  frame  or  .session. 

1/T9)  The  CCM  currently  does  not  specify  the  order  of  the  metafile 

descriptor  elements,  although  the  formal  gr.Tmmar  seems  to  hive  mere 
restrlrtlons  In  this  regard  i hnn  the  body  of  the  standard  would 
Indicate.  We  believe  It  would  he  a  good  Ide.i  If  the  first  four  MD 
Clements  were  the  METAFILE  VERSION.  METAFILE  ELEMENT  LIST,  MEIaFTLE 
CATECORC,  and  METAFILE  DESCRIPTION.  If  the  Addendum  does  make  this 
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a  raqulraatnt,  It  cannot  ba  axtandad  to  basic  category  CCM  for 
reasons  of  backward  compatibility  (although  It  can  be  noted  as 
"advice  to  generators"). 

Hote:  This  docs  not  natch  the  formal  grammar  of  the  CCM-IS  text. 

I/TIO)  In  Table  3(a),  there  arc  a  number  of  elements  permitted  In  states 
FO  and  FC  that  should  not  be.  These  arc:  CLIP  RECTANGLE  and  CLIP 
INDICATOR,  DEVICE  VIEWPORT  SPECIFICATION  MODE,  PREPARE  VIEW 
SURFACE,  and  UPDATE.  DEFERRAL  MODE  and  MARE  PICTURE  CURRENT  should 
probably  also  be  deleted  from  those  states,  as  they  make  no  sense  - 
there  Is  no  rendering  or  updatable  action  until  the  completion  of 
the  figure  definition. 

1/Tll)  In  Table  3(a},  END  FIGURE  and  NEW  REGION  should  only  be  permitted 
In  FO  and  FC. 

1/T12)  In  Table  3(a),  APPEND  TEXT  should  be  permitted  only  In  state  TO. 

1/T13)  BEGIN  METAFILE  should  appear  In  the  state  table  (Table  3(a))  or  in 
an  associated  note. 

1/TlA)  Annex  0  needs  to  be  completed  for  the  new  elements.  In  particular, 
what  Is  a  vector  device  recommended  to  do  wich  a  PIXEL  ARRAY? 

1/T15)  page  33:  The  DEVICE  VIEWPORT  should  default  to  (0,0)(1,1)  rather 
than  Implemcntat Ion  dependent  (since  the  default  VIEWPORT 
SPECIFICATION  UNITS  Is  "fraction  of  display  surface).  Taken  along 
with  the  default  DEVICE  VIEWPORT  MAPPING  of  isotropic',  this 
default  viewport  produces  the  largest  inscribed  square  which  fits 
on  the  workstation  display  surface. 

1/T16)  page  33;  PICK  IDENTIFIER'S  default  should  be  zero. 

1/T17)  7.5;  It  is  not  appropriate  to  specify  conformance  in  terms  of  the 

formal  grammar,  which  is  not  part  of  the  standard.  "Grammar"  would 
suffice  here. 

1/T13)  E.  8.  2  needs  a  corresponding  paragraph  for  generating  the  correct 
CCM  font  information  from  GKS. 

1/T19)  5.10.10;  The  order  of  the  enumerated  parameters  should  be 

(Invisible,  visible).  This  conforms  to  the  "null  value  rule". 

Also,  the  CCM  already  has  these  enumerated  types  bound  in  this 
order  for  the  edge  control  of  POLYGON  SET. 

1/T20)  5. 10. 13:  The  order  of  the  enumerated  parameters  should  be 
(undetectable,  detectable),  by  the  "null  value  rule". 

1/T21)  COPY  SEGMENT  should  be  permitted  in  state  PO.  to  accomp]  l.sh  what 
GKS  does  with  INSERT  SEGMENT  (copying  .n  segment  from  WISS  to 
nonretalned  data).  Table  3(a)  would  need  to  be  updated  as  well. 

Note:  This  is  a  resolved  CGI  issue  out  of  the  San  Diego  meeting 
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1/T22)  PIXEL  ARRAY  should  have  a  local  colour  precision  parameter  (like 
CELL  ARRAY  and  PATTERN  TABLE),  to  permit  compaction  of  the  colour 
list.  (Liaison  with  CCI  Is  required  before  this  change  Is  made;  we 
suggest  changes  to  both.  ) 

1/T23)  4.12.2.2:  END  SEGMENT  Is  not  allowed  In  the  metafile  descriptor, 
only  In  global  and  local  segments. 

1/T24)  Annex  H:  Only  the  mapping  of  CKS  functions  to  CCM  Is  given. 

Reference  is  made  to  Annex  E  for  the  reverse  mapping,  but  such  is 
not  provided  In  Annex  E.  A  reverse  mapping  should  be  given.  The 
mapping  should  be  from  CCM  element  to  CRSM  Item,  rather  than  CKS 
function,  since  (for  example)  the  correspondence  between  the  two- 
vector  CHARACTER  ORIENTATION  of  CCM  and  the  one-vector  "character 
up  vector"  of  CKS  Is  not  clear. 


Technical /Editorial  Comments 

1/TEl)  CLOBAL:  Readability  would  be  enhanced  by  defining  pseudo-data 

types  such  as  "CO:  Cl  or  CO,  depending  on  COLOUR  SELECTION  MODE', 
and  then  using  type  CO  for  the  SET  <X>  REPRESENTATION  elements. 
(Similarly  with  line  width,  edge  width,  and  marker  size 
parameters.  )  Reference;  CCI,  and  also  CCM  Part  3. 

1/TE2)  Clobal  comment:  All  or  almost  all  occvirrences  of  the  word 
"function"  should  be  changed  to  "element". 

1/TE3)  Clobal  comment:  The  words  "appear"  and  "appearance"  are 

overloaded  by  being  used  both  for  the  visual  appearance  of  a 
segment  or  primitive  on  the  display  and  for  the  occurrence  or 
presence  of  an  element  or  segment  In  the  metafile.  The  latter 
terminology  Is  preferred. 

1/TE<*)  Global  comment;  The  phrasing  throughout  about  "<prlmltlve>  Is 

drawn"  needs  to  be  modified  to  take  global  segments  Into  account, 
where  It  Is  actually  not  drawn  until  referenced  In  a  picture. 

1/TE5)  page  2;  METAFILE  CATEGORY  was  omitted  from  the  list. 

1/TE6)  T?fe  state  diagram  should  be  updated  to  reflect  the  new  states:  for 
readability,  this  might  require  more  than  one  diagram.  Although 
It  can  be  argued  that  Table  3(a)  contains  all  relevant 
information,  the  diagram  greatly  aids  comprehension. 

1/TE7)  We  suggest  renaming  category  CCMEXTl  to  CCMADDl,  since  this  is 
officially  an  Addendum  rather  than  an  Extension. 

1/TE3)  4.5.6.  paragraph  3:  "Another  device  viewport  spec  l  f  1  c.it  1  on  mode 

should  be  DEVICE  VIEWPORT  MAPPING  (see  m.irknp  for  other  edicori.ii 
changes  In  this  paragraph). 

1/TE9)  The  concepts  section  on  Closed  Figures  ( <•  a  P)  needs  to  n.se  murh 
more  of  the  te::t  from  CCI:  It  is  currently  i  ncomprehens  i  bl  e  to 
those  who  don  t  .i  I  ready  know  it.  At  Ic.i.st  otic  c:;.Tmple  with 
accomp.my  I ng  picture  is  needed  as  well. 
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1/TElO)  4.6.9:  Use  "spatial  aapplng"  to  distinguish  this  from  mapping  of 
colour  spaces  or  mappings  of  elements  from  CKS  to  CCM. 

1/TEll)  A  section  should  be  added  to  clause  4  describing  the  difference 
between  "pictures'  (delimited  by  BEGIN  PICTURE  and  END  PICTURE) 
and  "frames"  (delimited  by  Instances  of  PREPARE  VIEW  SURFACE).  we 
suggest  also  adding  a  "note"  (not  part  of  the  standard)  which 
offers  guidance  on  how  to  use  a  WISS  and  the  metafile  output 
workstation's  open/active  state  to  capture  Just  the  last  frame  In 
an  Interactive  session. 

1/TE12)  4. 12. 3. 2  and  elsewhere:  All  references  to  the  "CCI  pipeline" 
should  be  reworded.  This  document  should  be  reworded  to  avoid 
discussion  of  a  pipeline. 

1/TE13)  page  33:  UPDATE  has  no  default  and  should  be  deleted  from  the 
list. 

1/TE14)  Table  3(a):  It  should  be  clarified  that  many  elcment.5  allowed  in 
state  PO  can  also  occur  In  the  METAFILE  DEFAULTS  REPLACEMENT,  but 
are  correctly  listed  as  not  being  permitted  In  state  MD.  Perhaps 
another  column  should  be  considered  for  this  table,  for  state  OR 
(defaults  replacement). 

1/TE15)  Table  3(a),  formatting:  Please  repeat  the  column  headings  for 
each  page,  on  Table  3(a).  The  spacing  between  columns  is  not 
consistent. 

1/TE16)  5.3.17:  The  description  needs  to  be  rewritten*.  It  should  say  what 
the  MAXIMUM  VDC  EXTENT  Is.  How  It  Is  used  by  CKS  should  be 
specified  In  Annex  E  and/or  Annex  H. 

1/TE17)  5.5.9  says  "see  DEVICE  VIEWPORT  for  a  fuller  explan.it  ion '  -hut 

5.5.7  has  no  explanation  (It  should).  Please  Include  all  of  CCI  s 
5.3.5,  including  the  discussion  of  mirroring,  so  ihat  the  element 
has  enough  information  specified. 

1/TEI3)  5.  5.  10:  The  parameters  bnlg  and  bnll  should  be  condensed  to  bni  . 
to  match  the  description  and  resolved  issue. 

I/TE19)  5.5.12:  CCI  resolved  at  Valbonne  that  the  flag  is  applicable  to 
both  hardcopy  and  softcopy.  We  suggest  calling  the  formal 
parameter  "force  clear",  with  enumerated  values  (forced, 
cond  1 1  lonal ). 

1/TE20)  5.7.38:  The  parameters  are  not  In  same  order  as  CCI:  they  should 
be. 

1/TE21)  5.  7.  <»2:  "All  output  operations"  should  become  "rendering  of 
prlmlt Ives". 

1/TE22)  page  35,  point  4:  Although  a  user  cannot  specify  skewed  character 
up  vector  and  character  base  vector  at  the  CKS  API,  skewed  vectors 
can  result  at  the  CKS  wsi  if  the  segmentation  tr.insform.it  Ion  is 
applied  before  writing  the  Information  Into  the  meidfile. 

1/TE23)  page  1;  The  objective  of  "graphical  session  c.ipture"  does  not.  on 
the  surface,  appear  to  justify  the  Inclusion  of  elements  such  as 


133 


Draft  U-S*  Raaponsa  to  CCM  DPAD  1  Part  1 


1/TE2<.) 

1/TE25) 

1/TE26) 

1/TE27) 

1/TE28) 

1/TE29) 

1/TE30) 

1/TE31 ) 
1/TE32) 

1/TE33) 

1/TE34) 

1/TE3S) 

1/TE36) 

1/TE37) 

1/TE38) 


PICK  IDENTIFIER  and  PICK  PRIORITY.  If  the  Intent  Is  to  provide 
the  ability  to  replay  from  CCM  the  beginning  of  an  Interrupted 
session  In  CKS  and  then  continue  from  that  point,  this  should  be 
made  explicit.  Graphical  session  capture  should  be  defined  In  the 
glossary. 

Page  3,  4.4.4:  This  line  should  Instead  state  what  the  element 
specifies:  how  CKS  uses  It  should  appear  in  Annex  E  or  Annex  H  In 
a  full  discussion  of  how  the  mapping  takes  place. 

Page  lA:  What  Is  "Figure  Closed"  state?  This  doesn't  match  CCI 
and  makes  little  sense.  It  should  probably  be  "Figure  Open/Region 
Closed  '. 

Page  13:  The  document  would  benefit  from  an  overall  description  of 
the  states  and  their  transitions.  In  addition  to  Table  3(a). 

5.5.14:  MODIFY  FONT  LIST  -  second  parameter  should  be  nS  (list  of 
strings)  rather  than  S. 

5.5.16;  "ACTIVE"  state  should  be  replaced  by  "the  state  of  the 
metafile  prior  to  the  most  recent  BEGIN  FIGURE." 

5.5.17;  1st  sentence,  add  "except  In  global  segments,  where 
rendering  Is  deferred  until  the  segment  Is  referenced." 

In  the  description  of  Closed  Figures,  we  should  probably  not 
capitalize  line  and  fill  area  functions:  It  would  also  help  to 
state  at  the  start  that  these  refer  to  classes  of  primitives 
rather  than  specific  ones. 

5.5.19,  last  sentence,  "picture";  Add  "or  global  segment  . 

5.5.20,  notes  I  and  2:  Add  "for  use  In  restoring  the  value; 
however,  the  current  mode  is  not  restored.  "  AJ.so.  "escape 
function  Identifier"  should  be  "escape  element  Identifier  . 

page  17.  note  for  page  51  of  CCM;  This  should  be  clause  5  3  12. 
not  5.  3.  3. 

page  16;  The  data  type  "name  "  appears  never  to  be  used:  If  t  h  ■.  s  :s 
so,  It  should  be  deleted. 

page  30.  5.10.8  -  The  description  Is  clear  in  the  context  of  CCI. 
but  needs  to  be  rewritten  to  be  clear  In  the  context  of  CCM. 

4.5.4,  second  paragraph,  line  1:  "ready  to  accept  graphics  -oj^u 
be  clearer  .is  "ready  to  accept  graiihlc.nl  output". 

4.  (-.  8;  "curves"  should  he  '".arcs" 

Page  .  1st  sentence;  These  appc.ar  to  be  e;;.Tmplos  of  softc'';  • 
devices:  hardcopy  devices  arc  typically  printers,  plottcvb 
film  recorders. 
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Following  art  the  U.  S.  comments  on  segmentation.  Part  1. 


Teehnieal  ConBCatJI 

1/T2S)  Page  6,  section  A.  12. 1,  list  of  segment  elements: 

REOPFN  SEGMENT  should  he  a  delimiter, 

REDRAW  SEGMENT  is  absent, 

IMPLICIT  REGENERATION  MODE  Is  missing  the  word  "SEGMENT", 

PICK  IDENTIFIER  Is  absent. 

Add  a  paragraph  following  the  list  along  the  lines  of: 

"BEGIN  SEGMENT.  REOPEN  SEGMENT,  and  END  SEGMENT  are  delimiter 
elements  rather  than  segment  elements,  as  they  may  not  occur 
within  SEGMENT  OPEN  state.". 

1/T26)  page  28,  section  5.10.2,  first  paragraph: 

Replace  the  first  sentence  with:  "The  contents  of  the  Identified 
segment  are  copied  into  the  picture,  in  Its  current  state.  "  This 
Is  due  to  the  corresponding  changes  In  CGI. 

1/T27)  page  29; 

Add  a  new  section  for  REDRAW  SEGMENT,  which  was  omitted.  Renumber 
the  following  sections  appropriately. 

"Parameters; 

segment  tdenftfier,  (SN) 

Descript  ion: 

This  clement  Is  intended  to  result  in  a  redraw  of  the 
identified  existing  segment,  unless  the  segment's  visibility 
attribute  Is  INVISIBLE.  The  resulting  dl.splay  Is  implementation- 
dependent.  Any  segment  overlapping  the  Identified  segment  may 
also  be  redrawn,  depending  on  the  Implementation. 

The  effect  of  this  clement  Is  Intended  to  be  independent  of  the 
Implicit  segment  regeneration  mode." 


Itchnical  Editariai  CammanLa 

1/TE39)  page  1.  last  paragraph,  add: 

Segments  may  be  appended  using  REOPEN  SEGMENT  and  END  SEGMENT. 

l/TE<iO)  page  6.  section  <1.12.1,  Insert: 

Throughout  section  <*.  12  and  Its  subserflons.  the  concepts 
Involving  segments  .are  described  In  the  conier't  of  an 
Intel preicr ■ s  handling  thereof.  The  CCM  simply  stores  the 
elements  for  an  Interpreter  s  n.se.  1  nt  erprpt  a  t  Ion  of  elemenre 
that  do  n«)f  caffect  fln.al  picture  appocarance  Is  implementation- 
dependent.  e.  g.  PICK  lOENTIETER.  Thvs  Implomonint  Ion  dependonr  v 
m.ay  be  determined  l>y  other  Standards  (e.  g.  CKS.  PHICS.  etc  ).  s 
used  by  the  implementation  of  an  interpreter. 

page  6.  section  <#.12.1,  original  first  paragraph; 

Rephrase  "Segments  may  be;"  to  "Segments  m.ay  have  elements 
3S.soclated  with  them  to  control  1  nterpretat  ion  thereof;  ' 
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1/TE<.2) 


1/TE<.3) 


l/TEi.4) 


1/TE<.5) 

1/TE<.6) 


1/TE<.7) 


1/TEi.fl) 


l/TE^O) 


Rephrase  list  Items  a-f  to  be  non-verbs,  e.  g.  :  transformation, 
visibility  or  Invisibility,  highlighting,  front  to  back  ordering, 
detectability  or  undetectabliity,  and  deleting. 

Following  the  list,  change  "within  a  picture.  They  can..."  to  read 
"Segments  may.  .  . 

page  A,  section  4.13.2: 

The  phrase  "Local  Segments  ...  are  local  to  that  picture."  Is  a 
circular  definition.  Rephrase  to  "Local  Segments  ...  have  no 
existence  beyond  the  bounds  of  that  picture.  " 

page  6,  section  4.12.2.1: 

Add  "Global  Segments  may  not  be  reopened."  following  the  first 
sentence.  Replace  the  third  sentence  ('...  not  defined  or  known 
to  ..."  with  "They  are  not  a  part  of  any  picture  within  the 
metafile.".  In  4.12.2.1,  first  line,  "normal"  should  be  deleted: 
a  phrase  along  the  lines  of  "which  are  the  same  elements  used  to 
define  local  segments"  should  be  added.  Also,  "COPY"  should  be 
"COPY  SEGMENT". 

page  7,  section  <•.  13.  3.  2: 

END  SEGMENT  Is  not  allowed  In  MD  state.  It  Is  only  allowed  In  SO 
state.  State  that  BEGIN  SEGMENT  changes  the  state  to  CSD. 

REDRAW  SEGMENT  Is  missing  from  the  list  of  segment  control 
elements. 

REOPEN  SEGMENT  should  not  be  a  segment  control  element,  but  rather 
a  delimiter  like  BEGIN  SEGMENT. 

Change  the  last  statemenr  of  the  second  p.nr.ngrnph  to  a 
parenthetical  comment  on  ihe  first  statement  of  that  paragrapli. 
e  g..  "(see  Table  3(a),  ...)." 

page  7.  section  4.12.2.3; 

Add  the  parenthetical  comment  "(see  Table  3(a).  ...)"  to  the  end 
of  the  first  sentence. 

p.4ge  7.  section  4.12.2.4; 

The  statement  "every  element  th.nt  Is  modally  defined  and  bound  tn 
primitives  ...  h.ns  a  well  defined  value."  Is  not  clear.  Reword  to 
state  that  there  are  "defaults". 

page  7.  sections  4.12.3.1  through  4.12.3.3: 

These  sections  should  be  4.12.3.2  and  4.12.3.3.  respectively,  and 
the  present  .section  4.  12.  3.  3  .shoii  Id  section  4.12.3.1.  slnru  3 
defines  terminology  'i.sed  by  ...  1  ;ind  .  2. 

p.ipe  7,  present  .section  4.  12.  3.  2: 

Rephrase  "passing  along  the  CCI  plpelinu  .are  stored  in  to  read 
"are  added  to". 

page  'I.  sect  ifin  4.  12.  3.  4; 

Reword  .along  the  lines  of; 

"Non-ret.a  I  neil  d.if.i  are  those  elements  present  in  a  picture,  but 
not  within  local  segments.  Any  handling  of  non-rctained  dat.n  by 
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an  Interprtttr  la  loplaaantat ion-dapandant ,  bayond  tha  rtqulremanc 
that  slmpla  display  of  a  aataflla  ptctura  aust  dljplay  cnat  non- 
ratalnad  data. " 

1/TESO)  paga  11,  sactlon  4.12.5.2,  first  paragraph: 

Changa  "pravant  tha  wasta  of~  to  "permit  an  intarpratar  to  save' 

1/TESl)  page  11,  sactlon  4.12.5.2,  third  paragraph: 

Remove  the  first  sentence,  as  it  Is  Inappropriate  to  a  metafile 
specification. 

1/TE52)  page  12,  section  4.12.6,  first  paragraph: 

Change  "open  segment"  to  "picture  definition  In  Its  present 
state". 

1/TE53)  page  16,  section  5.2.6,  Description,  first  sentence: 

Rephrase  to  read:  "This  element  delimits  the  start  of  a  segment. 

1/TES4)  page  27,  section  5.7.41,  first  paragraph: 

Add:  "Usage  of  the  pick  Identifier  Is  Interpreter-dependent. 

1/TE55)  page  27,  section  5.7.41; 

Remove  the  second  paragraph  as  It  Is  Inappropriate  for  a  metafile 
specif icatlon. 

1/TE56)  page  28,  section  5.10.1: 

Remove  the  third  paragraph  as  It  Is  Inappropriate  for  a  metafile 
specif icat ion. 

1/TE57)  page  28.  section  5.10.2.  fourth  paragraph: 

Add  to  the  last  sentence:  ",  or  whether  the  current  state  list 
attributes  are  applied." 

1/TE58)  page  28,  section  5.10.2; 

Remove  the  third  paragraph  as  it  is  Inappropriate  for  a  metafile 
specif Icat Ion. 

1/TE59)  page  28,  section  5. 10.  3: 

Remove  "NOTE  and  make  a  single  paragraph.  Change  "BECIN 
SEGMENT"  to  Include  "or  RENAME  SEGMENT  . 

1/TE601  page  29,  section  5.10.4; 

Delete  the  second  through  last  paragraphs  .is  they  are 
inappropriate  for  a  metafile  specification. 

1/TE61)  page  29,  section  5.10.5,  Description: 

Add:  “Sub.scquent  references  to  the  segment  must  use  the  new 
segment  Identifier.  The  old  segment  identifier  is  freed  for  use 
In  ^  subsenueni  BEGIN  SEGMENT  or  RENAME  SCGMEtIT. 

1/TE62)  p.ige  29.  section  5.10.7; 

Delete  ihtf  second  par.ngr.oph  through  ihc  l.isi.  Revise  the  scem-H 
sentence  of  the  first  paragraph  to  read;  "The  IMPLICIT  SEGMENT 
REGENERATION  MODE  element  may  occur  In  the  EICT'IRE  OPLN  state 
only.  ■  Add  a  final  sentence  to  the  fir.st  p.i  ra  g  i  .i  piv.  Tlie 
Interpreter  it.self  determines  the  actions  required  to  sui’port  th.s 
element. 
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1/TE63)  page  31,  section  5.10.9: 

The  specification  for  the  'transformation  matrix'  parameter 
differs  from  that  for  COPY  SEGMENT,  and  from  the  corresponding  CCI 
specification. 

1/TE64)  page  32,  section  5.10.10: 

Delete  the  'NOTE'  as  It  Is  Inappropriate  for  a  metafile 
specification. 

1/TE65)  page  32,  section  5.10.13: 

Add  to  the  end  of  the  first  sentence:  ”,  depending  on  the 
functionality  of  the  metafile  Interpreter.  " 

1/TE66)  page  33,  section  5.10.14; 

Delete  the  second  paragraph  as  It  Is  Inappropriate  for  a  metafile 
specification. 
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Tha  following  coimnants  concarn  tha  formal  grammar  daflnad  for  CCM  DPAD  1. 
Whara  ralcvant,  tha  arrors  ara  tracad  bade  to  tha  CCM  standard. 

1/TE67)  Non-racurslva  oataflla  contants  production. 

As  wrlttan.  tha  non-tarmlnal  <mataflla  contants>  production  (page 
36)  daflnas  a  production  for  a  slngia  plctura  pracadad  by  0  or 
more  ascapa  alamants  and/or  0  or  mora  axtarnal  alamants,  and 
followad  by  0  or  mora  ascapa  alamants  and/or  0  or  mora  axtarnal 
alamants.  According  to  tha  grammar  spaclfled  In  addandum  1,  a 
slngia  plctura  Is  tha  only  parmlsslbla  saquanca.  This  Is  claarly 
In  conflict  with  part  4  of  tha  standard  ( spac If  1  cally  sactlon  <•  I. 
page  9)  which  daflnas  tha  minimally  corract  mataflla  as: 

BECIN  METAFILE 
METAFILE  VERSION 
METAFILE  ELEMENT  LIST 
END  METAFILE 

Whartas,  according  to  tha  addandum  1  formal  grammar,  tha  minimally 
correct  metafile  would  be: 

BECIN  METAFILE 
METAFILE  VERSION 
METAFILE  ELEMENT  LIST 
<plcture> 

END  METAFILE 


The  source  of  this  Inconsistency  Is  the  non-terminal  production 
<mctaflle>.  which  is  defined  as: 


<met.nflle>  ::-  <BECIH  METAFILE) 

<  Ident If ler> 

< metafile  descriptor) 
<m»taflle  contents) 
<END  METAFILE) 


According  to  tha  CCM  standard,  the  tmetaflle  contents)  production 
should  be  an  optional  production,  as  follows: 

<metaflle)  ::-  <BECIN  METAFILE) 

< ident  1  f  I er ) 

<mct.aflla  descriptor) 

<mataflla  contents)* 

<EN0  METAFILE) 


Indlc.Ttlng  th.at  the  tmetaflle  contents)  production  c.in  occur  0  or 
more  times  in  the  meiuflle  between  the  'metallic  Jcsctipior>  .and 
the  <FN0  METAFILE)  component. 

The  'aicgesred  rh.anccs  h.nve  been  hichlichicd. 
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1/T£68}  <natafllc  conttnts>  production  changed  from  the  CCM  standard. 

The  production  <metafi1e  conTent.e>  ha.s  been  altered  from  that 
which  Is  defined  In  the  current  CCM  standard.  Currently, 
<metaflle  contents)  is  defined  as: 

tmetaflle  contents)  <extra  element)* 

•  <plcture> 
i  <extra  clement)* 

Addendum  1  defines  the  <mctafllc  contents)  production  as; 

tmetaflle  contents)  textrn  element)* 

<pi cture) 

<extra  element)* 

According  to  the  CCM  standard,  the  variation  of  ^metafile 
contents)  defined  in  addendum  1  is  correct  and  the  variation  in 
the  standard  Is  incorrect. 


1/TE69)  Inconsistencies  between  formal  grammar  and  CCM  standard /addendum 

The  following  list  of  inconsistencies  between  the  formal  grammar 

and  the  CCM  standard  or  the  CCM  addendum  *1  text  were  found: 

1.  Section  /•.  12.  2.  2  specifically  allows  for  the  CLOBAl.  SECMTNT 
state  to  be  entered  from  the  METAFILE  DESCRXTTOR  state,  but 
the  grammar  does  not  reflect  this.  Due  to  the  fact  th.nt 
Clobal  Segments  c.nnnot  accept  the  same  cl.nss  of  elements  as 
Local  Segments,  the  definitions  of  the  (picture  element)  and 
(Optional  descr  clmt)  productions  -l J 1  have  to  be  modified, 
and  the  two  new  productions  will  be  defined  (  (local  segtnent 
clement)  and  (glob.nl  .segment  clement)). 

2.  Section  <t.  3  of  the  si.nnd.nrd  specifically  allows  Interveninc 
escape  or  extern.nl  elements  between  the  (BECIN  METAFILE)  and 
(metafile  descriptor)  components.  According  to  CCM  addendum 
1  form.nl  gr.nmmar  (.ind  also  the  CCM  st.nnd.nrd  s  formal  grammar 
no  esc.npe  or  e.xternal  elements  can  occur  between  (BEGIN 
METAFILE)  and  (metafile  descriptor). 

3.  The  formal  gr.nmmar  Indicates  an  ordering  of  elements  within 
the  Metafile  Descriptor  State  that  is  not  defined  by  the  CCM 
st.nnd.nrd  or  addendum  1.  The  specific  problems  (  i.  e. 
differences  between  the  grammar  and  the  te:(t  of  addendum  1) 
within  the  Metafile  Descriptor  St.nte  nre  listed  below.  : r. 
each  case,  the  stafoment  made  Is  the  t  nt  or  prct.n  i  i  on  of  t  do 
formal  grammar  (.iddendum  I  and  in  some  c.istfs  the  CCM  '"li 
.i.s  ■.■ell)  and  is  nor  n  r  c.s  t  r  1  c  i  t  f)ti  ilofincd  bv  the  'c;.i  of 
cither  .iddendum  1  or  the  .staiul.ird: 


1.  (MLfAFILE  VERSION)  must  be  the  second  element  in  .t 
s  y  n  t  .1  r  I  1 1- 1  y  c o  i  r  c  c  '  me  t . i  f  i  I  c 


h. 


(MHAKii.i;  DFSCR i rnofi) 

VERSION) 
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c.  <METAF1LE  CATEGORY)  can  only  occur  after  <METAFILE 
DESCRIPTION). 

d.  <MFTAFILE  ELEMENT  LIST)  (which  is  a  required  element  for  a 
syntactlcly  correct  metafile  according  to  the  standard) 
must  occur  before  any  of  the  optional  metafile  descriptor 
elements. 

e.  <HFTAFILE  CATEGORY)  is  a  dependent  production  associated 
with  <METAFILE  DESCRIPTION). 

U.  The  REOPEN  SEGMENT  element  is  in  reality  a  delimiter  element, 
and  as  such  alters  the  production  for  local  segments.  A 
transition  from  the  PICTURE  OPEN  state  to  the  LOCAL  SEGMENT 
state  can  occur  on  either  a  BEGIN  SEGMENT  element  or  a  REOPEN 
SEGMENT  clement.  This  change  is  reflected  in  the  new 
production  <local  segment  element). 


Based  on  the  above  items,  the  following  productions  must  be 
modified  or  added  for  the  addendum  1  formal  grammar  to  conform  to 
the  te.xt  of  the  CCM  standard  and  addendum  1: 


^metafile  descriptor) 


<optional  descr  elmi> 


(opr iona  1 

descr 

elmt ) - 

(element 

list) 

(opc ional 

descr 

elmt  >  <1 

(Version) 

(Opt ional 

descr 

el mr ) » 

(opt lonn 1 

de.scr 

elmt  > « 

(Version) 

(Opt lonnl 

de.scr 

elmt  >  -r 

(element 

1  '  St  > 

(opt Ional 

descr 

elmt  >  -> 

;  ;  .  (VDC  TYPE) 

tvdc  typo 

:  (MAXIMUM  COI.OIIR  INUFX) 

(Colour  index) 

:  (COLOUR  value  EXTENT) 

(red  green  bliie>  (  2  ) 

:  (METAFILE  OErAULPS  REPLACEMENT) 
(dement  default)* 

!  (FONT  LIST) 

(font  name)* 

:  (CHARACTER  SET  LIST) 

(charncter  set  definition)* 

:  (CHARACTER  CODING  ANNOUNCER) 

(Coding  technique  enumerated) 
I  (Scalar  precision) 

I  (esenpe  elenienr> 

I  (tf-'-if  ern.T  I  element) 

:  (MA.MMUM  VUC  EXTruT) 

(point)  i'  2  ) 

:  (Si:CMiNT  pRiORnv 
(mini  mum  e."  rent  > 

(  mn  •:  i  mum  o  ■  f  ('  ii  r  > 

:  (METAFILE  CATEGORY) 

(Category  enumerated) 

:  (global  segment  element) 
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<version>  <METAriLE  VERSION) 

<lnteger> 

<picture  eleoiant)  <eontrol  clement) 

!  <graphical  clement) 

!  tattrlbute  element) 

!  tescape  element) 

f  texternal  eJemcnt) 

!  <loeal  aagmant  clamant) 

<loeal  segment  clamant)  <BECXN  SEGMENT) 

<sagmant  name) 

<ellglblc  local  sag  picture  elem) 
<ENO  SEGMENT) 

I  <11E0PEN  SEGMENT) 

<sagmant  name) 

<cllglblc  local  sag  picture  elem) 
<END  SEGMENT) 

<global  segment  elamanc)::>  <BEGIN  SEGMENT) 

<segmant  name) 

<allglblc  global  sag  picture  elem) 
<END  SEGMENT) 


The  suggested  changes  have  beer,  highlighted. 

The  above  grammar  will  accomplish  rhe  following  mod  I f 1 ca t ! ons  to 

the  Interpretation  of  a  given  metafile; 

1.  The  global  SEGMENT  DEFINITION  state  can  be  entered  from  the 
METAFILE  DESCRIPTOR  state  without  allowing  the  elements 
specifically  prohibited  from  occurring  In  the  CLOR.M  SECMT'IT 
DEFINITION  state  from  appearing.  Tr.nn.sltlon  from  the  METAFILE 
DESCRIPTOR  state  to  the  GLOBAL  SEGMENT  DEFINITION  will  occur 
on  a  <BECIN  SEGMENT)  element. 

2.  The  LOCAL  SEGMENT  DEFINITION  state  can  be  entered  from  the 
PICTURE  OPEN  state  without  the  restrictions  that  apply  only  to 
global  segments.  Transition  from  the  PICTURE  OPEN  stare  to 
the  LOCAL  SFCMF.NT  DEFINITION  state  can  occur  on  either  BEGIN 
SEGMENT  or  REOPEN  SEGMENT. 

3.  The  modified  tmetaflle  descriptor)  production  requires  both 
<METAFILE  VERSION)  and  cMETAFILE  ELEMENT  LIST)  to  appear  In 
the  Metafile  Descriptor  state,  but  does  not  Imply  any  specific 
ordering  of  any  of  the  Metafile  I'cscripror  elcment.s.  lnri>idit,B 
the  two  required  Metafile  Descriptor  elements.  The  prodne : i ot, 
•ilso  allows  for  er-ttern.ii  or  c.sc.npc  elements  to  app*nr  before’ 
.'Miy  Metafile  Descriptor  oicmeni.  llO'«ever .  've  rccromend  rh.it 
rhe  .iddvndiim  te:ti  be  modified  to  sjiecify  the  position;,  of 
<MFTAFII.E  VERSION).  ^METAFILE  FI.FMENT  I.1FT>.  (METAFlI.r 

DESCRIPTION)  .nnd  <r-1CTAFII.E  CATFCORV,  This,  of  ronr-.c.  . . 

moan  that  the  .above  gr.imm.ir  i  .s  .ij.ao  ho  iiu'f)rrcct.  To 
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Inplcntnt  tha  US  proposal,  tha  <mataflle  descrlptor>  and 
<optlonal  dascr  almnt>  productions  would  have  to  be  changed 
to: 

<nata£lla  descrlptor>  <extra  alanient>w 

<METAFILE  VERSION) 

<METAF1LE  ELEMENT  LIST) 
<METAFILE  CATEGORY)© 

<METAFILE  DESCRIPTION)© 
(Optional  dascr  elmt)* 

(optional  dascr  elmo  (VDC  TYPE) 

(vdc  type) 

!  (MAXIMUM  COLOUR  INDEX) 

(Colour  index) 

!  (COLOUR  value  EXTENT) 

<red  green  blue>  (2) 

:  (METAFILE  DEFAULTS  REPLACEMENT, 
(element  default)* 

:  (FONT  LIST) 

(font  name)* 

!  (CHARACTER  SET  LIST) 

(Character  set  definition). 

!  (CHARACTER  CODING  ANNOUNCER) 

(Coding  technique  enumerated) 
!  (Scalar  precision) 

:  (escape  element) 

!  (external  element) 

!  (MAXIMUM  VDC  EXTENT) 

(point)  '2) 

:  (SEGMENT  PRIORITY  EXTENT) 
(minimum  extent) 

(maximum  extent) 

;  (global  segment  element) 

4.  The  modified  (optional  descr  elmnt>  produrrlon  allows  the 
transition  to  the  GLOBAL  SEGMENT  DEFINITION  state  from  the 
METAFILE  DESCRIPTOR  state,  and  also  removes  the  restrictions 
on  the  METAFILE  CATEGORY  element. 

The  non-terminal  productions  ( Idcnt  i leaf  ion) .  (metafile 
category),  (metafile  description),  (characteristics).  (segmeTU^, 
and  (eligible  picture  element)  productions  have  been  deleted. 

Some  of  these  errors  also  occur  in  the  current  CCM  standard  s 
formal  grammar.  The  above  productions  must  be  modified  to  cor-f 
the  current  formal  grammar. 


1/TETO)  Undefined  uon-terniluul  produrtlfju  (.Ti'ribuic  eiemoni). 


The  non- 1  er  mi  n.n  I  production  (element  dctmifv  f  n.icc  r.; 
.nddendum  1)  rcfcrcncc.s  .i  non- >  ermi  n.i  1  rrodiu- ’  ir)n  ^  t  i  '  r  i  Ln  •  c 
element),  yet  no-here  in  .iddendnm  I  or  'he  CCfl  't.iriftiril  s  •  - 

delined  .i  non- 1  erm  I  n.n  I  (’rndnetion  '  .i  i  t  r  i  tm  i  e  cl  extent)  t' 

that  this  Is  .1  iiimple  cdliorl.il  iTohlem.  .util  ih.n  .h.at  ..xr 
intended  .'.is  <■  pr  i  mi  i  i  ve  .itfrlbnie  element  v  liiher  'he  rcte’  ■ 
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to  <attribute  elemant)  must  ba  changad  to  <prlmltlva  attribute 
alamant)  or  tha  non-tarmlnal  production  <prlmltlva  attribute 
alemant>  (page  ^3  of  CCM  addendum  1}  should  be  changed  to 
<attrlbute  element). 

This  error  occurs  In  the  CCM  standard  as  well  as  CCM  addendum  1. 

1/TE71)  Multiple  definition  of  non-cermlnal  production  <polnt>. 

The  nnn-termlnal  production  <polnt>  Is  defined  Identically  In  both 
sections  ’'■.3.2.  page  39  (Metafile  Descriptor  Elements)  and  F.  3.  3. 
page  39  vPlcture  Descriptor  Elements)  In  keeping  with  the 
convention  used  in  the  rest  of  the  formal  grammar,  a  production 
should  only  be  defined  In  the  section  which  first  uses  the 
production  (In  this  case,  section  F.  3.  2). 

This  error  does  not  occur  in  the  CCM  standard. 


1/TE72)  Vlol.itlons  of  the  CCM  standard  in  PARTIAL  TEXT  state. 

The  PARTIAL  TE.XT  state  is  entered  by  the  following  production: 

cnonffnal  character  list)  <NOT  FINAL) 

<strlng) 

<character  attribute  list) 
<spanned  text) 

There  .^re  multiple  problems  with  this  production  and  the 
productions  which  are  invoked  as  a  result.  The  following  problems 
have  been  noted; 

1.  The  non-terminal  production  <character  attribute  list)  Is  not 
defined  in  the  grammar.  A  production  <char  attribute  list)  is 
defined  which  appear  to  be  what  was  Intended.  This  Is  just  an 
editorial  problem  which  does  not  exist  In  the  CCM  standard. 

2.  The  production  <char  attribute  list)  does  not  accurataly 
reflect  i he  elements  which  are  permitted  to  occur  In  r he 
PARTIAL  TEXT  state.  To  reflect  tho  syuta:t  specified  by  the 
.standard,  a  new  non-terminal  production  <partlal  text 
.utrlbutes)  should  be  created  and  the  <nonfi!ial  character  lls:> 
production  modified  as  follows: 

<nontlnai  character  list)  <NOT  FINAL) 

tstrlng) 

<partlal  text  attributes)* 
'sp.inncd  text) 

<p.irti.Tl  tc:;i  .i  1 1  r  i  bu  t  cs )  <Tn.’''T  TCMT  ItirrX) 

' pos i f 1  VO  i ni egcr  > 

:<Tr.:’:  r  pri;c i  .siori) 

<io'T  precision  O'luntc.' n  r  c;i 

; /Cii.'iR  \CTr Tv  r;<p Mpijcrj  r  ,cr:  . 

<  r  L*  ,n  1  > 

:  ^ciiaracttr  np\cific> 

<  re.n  1  ) 

144  : <TrXT  COLOUR) 
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<coJ  our> 

!  <CHARACTER  IIEI'  T. 

<non-neg3 t 1 ve  vrtc  value> 
!<CHARACTER  SET  :MDEX> 

<posltlve  Index) 

!<ALTERNATE  character  set  IMDEX) 
<positlve  Index) 

:<text  bundle  indeX) 

<posltlve  Index) 

! <AUXILIARY  COLOUR) 

<colour  ) 

: <TRANSPARENCY) 

<on-off  indicator  enumerator) 

The  suggested  changes  have  been  highlighted. 

The  elements  which  are  permitted  to  occur  In  the  PARTIAL  TEXT 
state  arc  defined  in  the  CCM  standard  by  both  Figure  12  (page  <*0. 
State  diagram)  and  section  5.  A.  A  (p.ige  6'<  .  APPEND  TEXT). 

This  error  occurs  in  the  CCM  standard  as  well  as  CCM  DPAD  1. 


1/TE73)  Editorial  inconsistency  in  <TEXT  REPRESENTATION)  production. 

The  comments  for  the  character  expansion  factor  and  the  character 
spacing  components  of  the  < 1  EXT  REPRESENTATION)  alternative  of  the 
<representat  ion  element)  production  (page  are  associated  with 

the  wrong  components  based  on  the  descrtsrton  of  TEXT 
REPRESENI ATION  in  section  5.7.33  (page  25)  The  production  reads 


(representation  mode) 


(TEXT  REPRESENTATION) 

<  pos  1 1  i  ve  i  .'iciex  > 

(  i  nde::  >  i  f  ont  ! 

(text  precl.sion  enumerated) 
<real>  (character  spacing) 
<rtal)  (expansion  factor) 

(colour ) 


yet  the  text  of  (he  .addcnduiii  I  nd  i  c.a  t  o.s  the  prod  nr  i  i  on  '^hmild  -c*; 
.as 

( r  epre. soil  .1 1  Ion  ntodo 


cci 
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<Tr”T  r.!  ppr'ir’M  -.nc’;  ■ 

>*  pr>^  i  M  •/I*  j  f nJ  I'  > 

<  i  tuK'::  >  <  I  ofi  t  ■ 

provision  wMuimc  t  1  od  > 
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<rial>  (axpanslon  factorl 
<raal>  (eharactar  spacing) 
<colour  > 


The  suggested  changes  have  been  highlighted. 

]/TE7<i)  Editorial  Inconsistency  In  <FILL  REPRESENTATION)  production. 


I 

I 

I 

I 


The  fill  colour  specifier  component  of  the  <FTLL  REPRESENTATION) 
alternative  of  the  treprespntat ion  element)  production  (section 
F.  3. 6,  page  A6)  is  In  a  conflicting  position  with  respect  to  the 
definition  of  FILL  REPRESENTATION  (section  5.7.39,  page  25)  In  the 
addendum  1  text.  The  production  currently  reads 

<representat Ion  mode> 


!  <F1LL  REPRESENTATION) 

<posltlve  Index) 

(Interior  .style  enumerated) 
(Index)  thatch  Indext 
(positive  Index)  ipattern  Itidexj 
(colour) 


According  to  the  description  of  FILL  REPRESENTATION  in  section 
5.7.39,  the  production  should  read: 

(representation  mode) 


BEST 

AVAILABLE  COPY 


(FILL  REPRESENTATION) 

(positive  index) 

(Interior  style  enumerated) 
(colour) 

(Index)  ih.ntch  Index  i 
(positive  Index)  ipattern  Inderd 


The  siiggvsivU  chntiges  h.ivc  lieen  I: i  (:h I  I  phi c<l. 


1/TF75)  /SFT  DEFERRAL  MODE)  produrlinn  suliM  i  i  iit  ed  Inr  'iJirCRRAL  llOliI  > 

The  non- f  erm)  n.i  I  pr  mitir  l  I  ons  #iomrr»l  tfloMnjiU)  (socrion  (  3  . 

p.nge  j'M.  (Clltlhlo  roniit)|  cIvmcniN  fsccilon  F  3.2.  p.i^o  jJ: )  .if,| 
/clement  n;ime  cinimer.it  ed )  (scrtlon  F.  <«  ,  p.ipe  51)  ill  ro  I  to  <>iir  c  . 
tcrminnl  proilncllon  (SET  DEFFRRAl.  HODF)  vhlch  I  .s  never  ilcflnel 
It  ippc.irs  that  the  Inienilcd  tcrmln.1l  proilurtinii  -.m.*  <n)rrnR.\l 
MODI  ),  The  clement  In  I  ho  toxi  ol  the  .uliieiulum  Is  UEFCRRAI.  llOl;!.. 
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I 

I 

I 

i 

i 

I 

I 

I 

I 

I 

I 

I 

I 

I 


Draft  U<S>  Raaponsa  to  CCM  OPAO  1  Part  1 


1/TE76)  <metrlc  scale  factor)  mistyped. 

The  <metrlc  scale  factor)  production  (section  F.  3.  <• ,  page  ^0)  was 
mistyped  as: 

<metrlc  scale  factor)  !  <real) 

which  Is  a  semantically  null  production,  as  well  as  Incorrect 
syntax  for  a  BNF  grammar.  The  correct  BNF  for  this  production  Is 
the  same  as  was  specified  In  the  CCM  standard: 

<matrlc  scale  factor)  <real> 

The  suggested  modification  has  been  highlighted. 


1/TE77)  Complete  the  productions  for  those  elements  not  yet  defined. 

The  productions  ^eligible  local  seg  picture  elem>  and  <ellglble 
glob.il  seg  picture  eiem>  must  be  completed  from  the  state  table 
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Th«  U. S.  disapproves  of  Parc  2  of  CQl  PDAD  1  (SC  24  N  20)  vlch  the  following 
conwcnts: 

T.ghniesl  gdltorlal  Conmillta 

2/TEl)  Page  1,  "Add  the  following  to  table  1:" 

Add  the  8  bit  opcodes. 

2/TE2)  Page  2,  8.  2.  16 

GLOBAL:  Add  a  blank  line  before  the  production  of  a  non-terminal 

as  the  CCM-IS  text  does.  For  example: 

<METAFILE-CATECORY-opcode:  3/1  3/0> 

<enufflerated:  aetaf lle>cacegory> 

•«**  blank  line  goes  here 

<tnumerated:  aetaf lle-cacegory>  ■  <lnteger:  0>  (cgm) 

<lnteger:  1>  (gksm) 

<lnteger:  2>  icgmaddli 

Use  "cgmaddl"  Instead  of  "cgmextl*. 

2/TE3)  Page  2,  8.  2.  17 

<polnt;  first  corner)  and  <polnt:  second  corner)  should  be  called 
<polnt:  high  value)  and  <polnt:  low  value)  as  In  the  functional 
specification  (5.  3.17). 

2/TE<.)  Page  3.  8.  3 

"NOTE;  Default  not  consistent  with  CKS"  Is  not  appropriate  here. 
Perhaps  It  should  be  in  Clause  6. 

2/TE5)  Page  3,  8.  10 

"SET  DEFERRAL  MODE"  should  be  called  "DEFERRAL  MODE"  as  In  the 
functional  specification. 

2/TE6)  Page  3.  3.  <«.  U 

<font-declarat Ion)  Is  inconslstanc  with  the  functional 
specification  and  the  other  encodings.  Replace  <font-declarat lon> 
with  <fonc-names). 

2/TE7)  Page  .  8.  20 

The  data  type  of  attribute  set  name  Is  defined  as  ASN  In  the 
functional  specification,  but  Is  shown  as  Integer  In  the  character 
encoding.  The  character  encoding  should  be  <asn:  attribute-set- 
name)  Instead  of  tlnteger;  attrlbute-set-namc>. 

2/TE8)  Page  ^/5.  8. 5.  21 

The  last  four  parameter.s  are  not  In  the  functional  specification 
or  In  other  encodings  and  should  be  removed. 
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2/TE9) 


2/TEIO) 


2/TEll) 


2/TE12) 


Page  6 ,  8.  6.  38 

The  order  of  character  spacing  and  character  expansion  Is  reversed 
from  the  functional  specification  (5.7.38). 

The  non-terminal  <eolour-specif lcr>  should  be  expanded. 

Page  6.  8.  6.  39 

The  order  of  the  parameters  Is  not  consistent  with  the  functional 
specification  (5.7.39). 

<lntegcr:  colour-lndex>  should  be  expanded. 

Page  7,  8.  9.  1 

SN  Is  shown  as  a  data-type  In  tha  functional  specification 
(5.10.1).  <lnteger:  segment-ldent 1 f ler >  should  be  <sn:  segment- 
identifier).  This  comment  applies  to  all  occurences  of  segment- 
identifier  In  this  part. 

The  non-termlnal  production  of  <enumerated:  setting)  should  be: 

<enumerated:  setting)  *  tlnteger:  0)  (state  list) 

cinteger:  1)  (segment) 


Page  8  ,  a.  9.  8 

The  order  of  undetectable  and  detectable  is  reversed  from  the 
functional  specification. 
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Tha  U.  S.  disapproves  of  Part  3  of  CGM  PDAD  1  (SC  24  N  21)  with  Che  following 
comncnts: 

Taehnleal  CQminta 

3/Tl}  Page  1,  "Add  the  following  to  table  2:~ 

There  should  be  only  one  class.  Having  two  classes  Is 
Inconsistent  with  the  rest  of  the  addendum.  This  also  uses  a 
class  unnecessarily. 

Tgchnisal  Editorial  Comments 

3/TEl)  Page  1,  "Add  the  following  to  table  It" 

Replace  all  of  the  lS‘s  with  lp*l‘s  as  In  the  CCM-IS  text. 

3/TE2)  Page  1,  "Add  the  following  to  Item  10:" 

The  Metric  Scale  Factor  parameter  in  the  CCM-IS  text  Is  restricted 
to  be  only  In  IEEE  floating  point  format.  If  Scale  Factor  In 
Device  Viewport  Specif Icat ion  Mode  In  CCM  Addendum  1  Is  allowed  to 
be  fixed  point  format,  then  the  distinction  between  the  two 
separate  scale  factors  oust  be  clearly  stated  In  Item  10. 

3/TE3)  Page  1,  "Add  the  following  to  table  3:" 

There  should  be  a  blank  line  between  "BEGIN  SEGMENT:  has  1 
parameter"  and  "PI:  (segment  name)  segment  Identifier". 

3/TE<*)  Page  1/2,  "Add  the  following  to  table  note  16 

Replace  cgmextl  with  cgmaddl. 

3/TE5}  Page  2,  "Add  the  following  to  table  6;" 

DELETE  ATTRIBUTE  SET  Is  Incomplete. 

3/TE6)  Page  2.  "Add  the  following  to  table  6:",  note  7 

"first  point"  and  "second  point"  should  be  called  "first  corner 
and  "second  corner*  as  in  the  functional  specification  (5.5.7). 

The  discussion  of  the  default  DEVICE  VIEWPORT  should  be  moved, 
removed  or  added  to  Clause  6. 

3/TE7)  Page  4,  "Add  the  following  to  table  7:" 

Add  the  discussion  for  each  possible  colour  mode  as  In  the  CG.M-:s 
text. 

3/TE8)  Page  4/5,  "Add  the  following  to  table  8:".  note  38 

P4  and  P5  are  reversed  from  the  function.il  specification  (5."  35' 
3/TE9)  Page  4/5.  "Add  the  following  to  table  8:",  note  39 

The  values  are  missing  for  P2. 
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Tht  order  of  the  parameters  Is  inconslstant  with  the  functional 
specification  (5.7.39). 

3/TElO)  Page  6,  7.10,  Table  11 

INHERITANCE  FILTER  default  should  be:  n/a.I. 

3/TEll)  Page  6,  7.10,  Table  11.  note  2 

"PT;  (real)  y  translation  component"  should  be  "PT:  (vdc)  y 
translation  component". 

3/TE12)  Page  6,  7.10,  Table  11.  note  8 

Parameter  numbers  are  missing. 

3/TE13)  Page  7,  “The  following  forms  sub>clause  7.11:" 

See  GLOBAL  note  at  the  beginning  of  the  comments  on  the  binary 
encoding  as  to  whether  there  should  be  two  classes. 

3/TElA)  Page  8.  7.11.  Table  12.  note  2 

The  order  of  “visible"  and  “invisible"  is  reversed  from  the  EDGE 
VISIBILITY  element  in  the  CGM-IS  text. 

3/TE15)  Page  8,  7.11.  Table  12.  note  6 

The  last  sentence  Incorrectly  uses  the  phrase  .  .  segment  display 
priority..."  Instead  of  “...segment  pick  priority..." 
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Th«  U.  S.  disapproves  of  Part  4  of  CCM  PDAD  1  (SC  24  N  22)  with  the  following 
comments: 


Teghnleal  Comffiixm 


4/Tl) 


Page  8,  6. 11 

As  per  the  notes  In  previous  encodings,  combine  6.10  and  6.11  Into 
one  group  of  elements. 


T«ehnteei  Edl;orUI  CoMgnta 

4/TEl)  Page  1,  "Add  the  following  to  the  end  of  sub-clause  5.3.5: 

The  description  of  TM  Incorrectly  calls  the  matrix  a  "real 
transformation  when  It  Includes  VDC  types  as  well  as  reals. 

4/TEl)  Page  1,  "Add  the  following  to  the  end  of  sub-clause  5.  <*.  3: 

Suggested  abbreviation  changes:  DEV  Instead  of  DEVICE,  VPORT 
Instead  of  VIEW 

The  U.  S.  recommends  that  the  Language  Bindings  Working  Croup  be 
consulted  to  Insure  consistency  of  abbreviations  used  In  tlus 
document. 


4/TE3)  Page  1/2,  "Add  the  following  to  the  end  of  sub-clause  5.  <*.  *•: 


back  is  the  abbreviation  for  BACKGROUND  In  the  CCM-IS  text.  The 
US.  suggests  that  BKWO  be  used  as  the  abbreviation  for 
Backwards.  The  U.  S.  also  suggests  using  HILITE  Instead  of 
HIGHLIGHT  as  the  abbreviation  for  HIGHLIGHTING.  The  U. S. 
suggests  not  abbreviating  RESTORE. 


A/TE/i)  Page  2,  "Add  the  following  to  the  end  of  sub-clause  5.  <•.  5; 

circular  arc  centre  backwards  ARCCTRBACK  should  be  consistent 
with  whatever  la  chosen  for  BACKWARDS  In  sub-clause  5. « 
Suggested  ARCCTRBKWD. 

a/TES)  Page  3,  "Add  the  following  to  the  end  of  sub-clause  6.  3: 


Replace  CCHEXTl  with  CCMADDl. 

HIGH  and  LOW  is  used  In  the  functional  specification  and  should  be 
used  here  Instead  of  FIRST  and  SECOND. 

4/TE6)  Page  3.  "Add  the  following  to  the  end  of  sub-clause  6.  5: 

The  note  about  defaults  does  not  belong  here. 

4/TE7)  Page  3/4.  "Add  the  following  to  the  end  of  .sub-clause  6.  5:  . 
DEFERRAL  MODE 


deferral  mode  has  no  parameters  so  It  does  not  need  <S0FTSEP> 
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A/TES) 


4/TE9) 


A/TEIO) 

4/TEll) 


<./TE12) 


A/TE13) 


Page  Zl<*,  "Add  the  following  to  the  end  of  sub-clause  6.5:  ’, 
MODIFY  FONT  LIST 

There  should  be  <OPTSEP>  Instead  of  <SEF>  before  <S:  FONTNAME>. 

tSEPxS:  FONTNAME>  should  be  <<SEP>  <S:  FONTNAME>  >. 

Page  3/4,  "Add  the  following  to  the  end  of  sub-clause  6.5:", 
CHARSETDESICNATOR 

First  <SEP>  .should  be  <SOFTSEP>  as  In  the  original  encoding. 
<HARDSEP>  should  be  replaced  with  <S£F>  as  In  the  original 
encoding. 

Page  5,  "Add  the  following  to  sub-clause  6.6:",  PIXEL  ARRAY 
Remove  <LOCLCOLRSPEC>. 

Page  5/6.  "Add  the  following  to  sub-clause  6.7:",  TEXT 
REPRESENTATION 

The  order  of  <SPaCINC>  and  <FACTOR>  Is  reversed  from  the 
functional  specification. 

Page  5/6,  "Add  the  following  to  sub-clause  6. 7;~,  FILL 
REPRESENTATION 

Parameter  order  does  not  match  functional  specifications. 

Page  8,  6.11  ,  SEGMENT  VISIBILITY 
Reverse  the  order  of  VISlINVIS 


The 
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APPENDIX  4 

SUMMARY  ARTICLE  OF  THE  BLAXENEY  MEETING  OF 
THE  SPECIAL  WORKING  GROUP  ON  FUTURE  PLANNING 
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Graphics  Standards 

The  Future  of  ISO  Graphics  Standards 


At  its  first  plenary  meeting  in 
Berlin  during  December  of  1987, 
ISO/IEC  JTC1/SC24  (the  computer 
graphics  committee)  recognized  the 
need  to  evaluate  the  work  under* 
taken  by  its  predecessor  committee 
(SC21/WG2)  and  to  plan  for  the 
future  development  of  graphics 
standards.  SC24  authorized  the  for¬ 
mation  of  a  Special  Working  Group 
on  Future  Planning  with  the  char¬ 
ter  to  recommend  a  five-year  strate¬ 
gic  plan  for  organizing  the  work  of 
SC24.  The  group  was  also  to 
address  the  feasibility  of  developing 
a  unified  structure  for  relating  com¬ 
puter  graphics  standards,  to  iden¬ 
tify  new  areas  of  computer  graphics 
that  should  be  covered  by  a  stan¬ 
dard,  and  to  make  appropriate  state¬ 
ments  regarding  the  relationships 
of  computer  graphics  standards 
with  standards  in  other  areas.  In 
addition  the  group  was  chartered  to 
define  areas  in  which  computer 
graphics  standards  need  to  be 
reevaluated  or  extended  or  where 
new  standards  need  to  be  developed 
to  meet  user  requirements. 

The  Special  Working  Group  met 
at  Blakeney,  England,  from  April  11 
to  .April  13.  1988.  Sixteen  delegates 
from  six  national  bodies  were  in 
attendance.  The  group  was  able  to 
reach  consensus  regarding  how 
graphics  standards  should  be  devel¬ 
oped  in  the  future  and  how  the 
present  work  of  SC24  should  be 
concluded.  This  consensus  was 
presented  to  SC24  at  its  plenary 
meeting  held  earlier  this  month  in 
Tiicson,  Arizona. 


Lessons  learned 

The  group  spent  some  time 
enumerating  lessons  learned  since 
the  formation  of  SC21/WG2.  These 
lessons  are 

1.  There  should  be  fewer  imple¬ 
mentation  dependencies  in 
SC24  standards. 

2.  Precise  scope  and  goals  must  be 
agreed  to  before  development 
starts  on  a  New  Work  Item 
(NWI). 

3.  Allowing  enhancements  to 
occur  during  the  standardiza¬ 
tion  process  thwarts  timely 
standards. 

4.  Continuity  of  staffing  cannot  be 
assumed  throughout  a  stan¬ 
dards  activity. 

5.  Timely  development  is  required 
if  standards  are  to  be  usefuL 

6.  A  single  reference  model  would 
have  expedited  current  stan¬ 
dards  activities  significantly. 

7.  The  text  model  in  the  current 
generation  of  computer 
graphics  standards  is 
inadequate 

3.  The  input  model  adopted  for 
GKS.  GKS-3D.  and  PHIGS  is 
inadequate  to  specify  quality 
user  interfaces. 

IVends 

The  group  reached  consensus 
that  the  following  trends  exist  and 
should  influence  future  work  of 
SC24; 

1.  Windowing  technology  cannot 
be  ignored. 

2.  Integration  with  standards  in 
other  areas  has  become 
essential. 

3.  Domain  speciHc  standards  are 
becoming  more  necessary. 

4.  There  is  increasing  use  of 
graphics. 

5.  De  facto  "standards”  have 
begun  to  influence  computer 
graphics  standards  work. 


Options  for  progressing  SC24 
work 

The  Special  Working  Group 
defined  and  considered  seven 
options  for  progressing  SC24  work: 

L  Produce  a  basic  reference 
model  by  the  1989  SC24  meet¬ 
ing  and  suspend  all  SC24  work 
not  at  the  DIS  (draft  interna¬ 
tional  standard)  stage  by  that 
meeting. 

2.  Start  work  on  a  new  framework 
for  describing  computer 
graphics  standards  and  use  this 
model  to  restructure  all  work 
not  at  the  DIS  stage  by  the  1989 
meeting. 

3.  Improve  existing  procedures 
based  on  lessons  learned. 

4.  Suspend  all  work  until  a  new 
reference  model  for  computer 
graphics  standards  is  developed 
and  reaches  the  DIS  stage. 

5.  Go  on  in  the  usual  way  and  dis¬ 
regard  all  lessons  learned  from 
the  past 

6.  Abandon  graphics  standardiza¬ 
tion  development 

7.  Acknowledge,  evaluate,  and 
recognize  de  facto  standards. 

In  evaluating  these  seven  options, 
the  group  considered  a  number  of 
criteria.  These  included 

•  the  impact  of  adoption  of  the 
option  on  the  timeliness  of  com¬ 
puter  graphics  standards 

•  the  quality  of  standards 
produced 

•  the  possible  increase  or  decrease 
in  staffing  of  Rapporteur  Groups 

•  the  risk  involved  to  the  eventual 
production  of  a  family  of  high- 
quality  computer  graphics 
standards 

The  Special  Working  Group  con¬ 
cluded  that  options  1  and  2  repre¬ 
sented  the  most  realistic  ways  to 
proceed.  Option  3  was  considered  a 
rather  poor  fallback  option.  The 
group  recommended  that  a  strategy 
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be  devised  based  on  appropriate 
combination  of  options  1  and  2  that 
would  synthesize  their  best 
features. 

Componant/framework  modal 
for  tha  davalopmant  of  standards 

The  Special  Working  Group  con¬ 
cluded  unanimously  that  a  refer¬ 
ence  model  is  need^  to  unite  SC24 
standards,  and  that  standards 
should  be  developed  in  a  different 
manner  in  the  future  from  that  used 
in  the  past.  The  group  recommended 
an  approach  to  developing  standards 
which  they  called  the  “Compo¬ 
nent/Framework  Process."  In  this 
approach  components  might  be,  for 
example,  data  types,  operations,  or 
attributes,  and  frameworks  might  be 
considered  the  “glue”  that  takes  a 
set  of  data  types  and  operations  and 
constructs  a  standard  from  them. 

The  group  recognized  that  con¬ 
siderable  technical  work  is  needed 
to  decide  the  beat  way  of  structur¬ 
ing  the  SC24  standards  in  terms  of 
components  and  frameworks  and  to 
define  necessary  formal  methodolo¬ 
gies  and  interface  techniques  to 
allow  portions  of  standards  to  be 
developed  independently  as  compo¬ 
nents  and  subsequently  integrated 
by  frameworks. 

The  group  suggested  the  follow¬ 
ing  items  that  might  be  components 
in  SC24  standards: 

•  primitive  data  types 

•  rendering  attribute  data  types 

•  transformation  operations 

•  storage  data  types 

A  framework  might  include 

•  datatypes 

•  sequencing  of  operations 

•  deferred  modes 

•  display  timing  and  control 
The  figure  illustrates  how  com¬ 
ponents  relate  to  frameworks  in  the 
development  of  standards.  Sets  of 
components  are  tied  together  into 
one  or  more  standards  by  a  frame¬ 
work  structure.  Compatibility  is 
achieved  among  various  standards, 
since  they  incorporate  common 
components. 

Recommend*  tioni 

The  Special  Working  Group  made 
a  number  of  recommendations  to 
SC24  and  its  working  groups.  Five 
output  documents  were  produced 
for  consideration.  These  output 
documents  include  a  description  of 


the  component  framework  model 
for  developing  standards  and  a  five- 
year  planning  document  for  SC24. 
The  principal  recommendations  of 
the  Special  Working  Group  were  the 
following: 

1.  SC24  should  adopt  a  new  struc¬ 
ture  for  the  next  generation  of 
computer  graphics  standards, 
which  will  require  a  new  devel¬ 
opment  process. 

2.  SC24  should  suspend  or 
restructure  under  the  new 
development  process  any 
projects  for  semantic  standards 
not  at  the  level  of  DIS  or  DAD 
(draft  addendum)  by  the  1989 
SC24  meeting.  (The  effect  of 
this  recommendation  is  to 
divide  SC24  standards  into  a 
first  generation  of  semantic 
standards,  including  GKS, 
GKS-3D,  PHIGS,  CGM.  and- 
assuming  work  can  be  com¬ 
pleted  in  time— CGI  and  CGM 
addenda,  and  a  second  genera¬ 
tion  of  semantic  standards 
developed  under  the  new  com¬ 
ponent  framework  process.) 

3.  SC24  should  consider  window¬ 
ing  and  imaging  as  part  of  the 
next  generation  of  graphics 
standards. 

4.  SC24  standards  must  interwork 
with  standards  in  the  areas  of 
office  systems,  image  capture, 
and  Standards  for  the  Exchange 
Product  Model  Data  (STEP). 

SC24  standards  must  also  func¬ 
tion  in  an  Open  Systems  Inter 
connection  (OSI)  environment 


and  as  components  of  an  Open 
Distributed  Processing  (ODP) 
environment. 

Conclneions 

If  the  recommendations  of  the 
Special  Working  Group  are 
endorsed  by  all  of  SC24.  they  will 
have  a  profound  impact  on  the 
future  of  computer  graphics  stan¬ 
dards.  They  should  force  work 
already  under  way.  which  has  been 
severely  delayed  hy  "creeping  fea¬ 
tures,”  either  to  be  completed 
within  the  next  year  or  to  be 
dropped.  SC24  will  have  the  oppor¬ 
tunity  to  develop  a  second  genera¬ 
tion  of  standards  based  on  an 
integrated  reference  model,  thereby 
avoiding  many  of  the  "compatibil¬ 
ity”  problems  which  have  been  per¬ 
ceived  in  the  first  generation  of 
computer  graphics  standards.  ■ 

Gearjc  s.  Carson  is 

president  of  CSC 
•A.ssociates.  a  systems 
engineering  consulting 
firm  specializing  in  real¬ 
time  signal  and  informa¬ 
tion  processing  systems. 
He  has  mm-e  than  '.5 
years  experience  build¬ 
ing  systems  incorporat¬ 
ing  multiple  processors,  computer  networks, 
and  interactive  graphical  user  interfaces.  Car- 
son  was  vice  convenor  and  chief  liaison  offi¬ 
cer  for  ISO  TC97/SC21/WG2.  where  he  was 
also  the  Rapporteur  for  Formal  Description. 
Ho  is  the  convenor  of  the  ISO/IEC  rTCl/SC24 
Special  Mbrking  Group  on  Future  Planning 
and  serves  as  document  editor  for  SC24  refer¬ 
ence  model  work,  in  ANSI  X3H3  he  is  chair 
of  X3H3.2.  with  responsibility  for  work  on 
format  descriptions,  reference  models,  user 
requirements,  and  X3H3  external  liaisons. 

^rson  leceived  a  PhD  in  mathematics 
irom  the  Uniwrsity  of  California  at  Riverside. 


My  19W 


157 


83 


This  page  left  intentionally  blank. 


158 


APPENDIX  5 

FIVE-YEAR  PLAN  PRODUCED  BY  SWG/FP 


159 


This  page  left  intentionally  blank. 


V 


160 


ISO 


ISO/IEC  JTC1/SC24  N 


ISO 

International  Standardization  Organization 
Organization  Internationale  de  Normalisation 


iso/iEcrrci/sc24 
Computer  Graphics 
Secretariat:  FR  of  Germany  (DIN) 


Title:  Towards  a  Five  Year  Plan  for  SC24 

Source  (Country,  Organization,  Committee):  Special  Working  Group  on  Future 

Planning 

Status:  □  SC24  Output  Document 

G  Member  Body  position 

□  Expert  opinion  (ALL  expert  contributions  submitted  to  SC  meeting  must  be 
au^oriz^  by  the  Member  Body). 

59  Working  Group  output 


Type:  SI  Al;  "Immediate"  Output  Document  from  WG/SC24  Meetings  (to  arrive  at 

SC24  Secretariat  2  weeks  after  meeting). 

□  A2:  "Delayed"  Output  Document  from  WG/SC24  Meetings  ( to  arrive  at 

SC24  Secretariat  4  weeks  after  meeting) 

□  B;  Nadonai/Expert  Contributions  to  WG/SC24  Meedngs  (to  arrive  at  the  WG  or 

SC  Secretariat  8  weeks  before  the  beginning  of  the  the  WG  or  SC  meeting) 

□  C;  Recent  Liaison  Documents  (to  arrive  at  the  expert  by  the  start  of  the  WG  or  SC 

meeting) 

Type  of  Distribution:  SI  Through  SC24  Secretariat 

□  Direct  to  Member  Bodies 

Date  of  Submission:  14  April  1988 


Keywords:  Future  planning 


161 


Towards  a  Five  Year  Plan 


SWG  FP/14 


1.  Introduction 

This  document  describes  deliberations  of  the  SC24  Special  Working  Group  (SWG)  on  Future 
Planning,  which  met  at  Blakeney,  UK  on  1 1-13  April  1988,  This  group  was  chartered  by  SC24  to 
make  reconunem^dons  on  how  best  to  proceed  with  the  development  of  Computer  Graphics 
standards.  The  formal  recommendations  of  the  SWG  are  contained  in  a  separate  document  (SC24 
N  ).  This  document  describes  how  the  group  assessed  the  current  state  of  Computer 
Graphics,  including  lessons  learned  f^m  past  standardisation  efforts  and  future  trends.  It  describes 
seven  alternative  strategies  defined  to  represent  the  range  of  options  available  to  SC24  in  the  pursuit 
of  its  future  work.  The  strategies  are  ev^uated  and  a  course  of  action  is  recommended.  Finally,  the 
likely  effects  of  the  group’s  recommendations  on  the  five  year  plan  of  work  of  SC24  are  assessed. 


2.  Current  state 

2.1  Introduction 

The  Special  Working  Group  spent  some  time  considering  the  current  state  of  Computer  Graphics 
standa’disadon,  reviewing  the  style  of  working  and  looking  at  the  possibilides  of  new  work.  The 
aim  was  to  see  what,  if  any.  consensus  could  be  achieved  and  how  that  would  effect  the  way  future 
work  was  organised. 

To  get  the  largest  breadth  of  ideas,  the  group  split  into  five  subgroups  and  the  conclusions  of  the 
subgroups  were  consolidated  into  this  portion  of  the  report.  Each  sub-group  was  asked  to  consider 
future  trends,  predict  what  effect  such  trends  would  make  on  future^work  and  whether  this  would 
lead  to  new  areas  for  standardisation.  Each  subgroup  was  asked  to  numerate  the  lessons  learned 
from  the  current  activities.  In  particular,  they  were  asked  to  assess  the  relative  advantages  of 
standardising  current  practice  and  developing  standards  appropriate  to  perceived  future 
requirements. 

2.2  Lessons  learned 

1)  There  should  be  fewer  implementation  dependencies  in  SC24  standards 

The  usefullness  of  existing  standards  has  been  impacted  by  the  high  level  of  implementation 
dependencies.  This  has  caused  problems  in  portability  and  made  conformance  difficult  to  assess.  A 
strong  recommendation  was  that  future  standards  should  have  much  fewer  impiementation 
dependencies. 

Implementation  dependencies  should  not  be  a  preferred  way  of  achieving  consensus  in 
controversial  areas.  TTiere  was  a  realisation  that  some  of  these  implementation  dependencies  were 
introduced  to  allow  support  in  a  wide  range  of  (sometimes  obsolete)  devices,  and  that  support  for 
such  devices  might  be  more  difficult  under  the  new  guidelines. 

2)  Precise  scope  and  goals  must  be  agreed  to  before  development  starts  on  a  NWI 

Much  effort  has  been  wasted  in  the  past  arguing  over  the  relationships  among  standards.  These 
arguments  could  have  been  avoided  by  spending  more  time  getting  precise  definitions  and 
agreement  of  scope  and  goals  initially.  Relationships,  or  the  lack  thereof  among  standards  must  be 
explicitly  agreed  before  starting  development 

3)  Allowing  enhancements  to  occur  during  the  standardisation  process  retards 
timely  standards 

All  current  standardisation  activities  have  sufferred  from  creeping  enhancements  that  appeared 
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during  the  review.  Adding  one  more  attribute,  primitive,  or  whatever  impacts  the  scope  and  goals, 
requires  the  agreed  functionality  to  be  reevaluated  and  may  violate  the  original  reference  model.  It 
was  believed  that  this  had  severely  impacted  the  timescales  for  current  standards.  If  such 
enhancements  are  anticipated  as  necessary  due  to  outside  development,  they  must  be  part  of  the 
planning  process  and  scheduled  in. 

4}  Continuity  of  staffing  cannot  be  assumed  throughout  a  standards  activity 

It  takes  at  least  four  years  to  produce  a  standard.  With  the  current  movement  of  graphics  staff  it  is 
unreasonable  to  believe  that  die  same  team  will  remain  intact  throughout  a  standards  development. 
Consequently,  there  is  a  need  to  capture  arguments  and  decisions  in  a  precise  way  so  that  education 
of  members  is  not  achieved  by  reworking  old  resolved  arguments. 

5)  Timely  development  is  required  if  standards  are  to  be  useful 

The  large  elapsed  time  for  standardisation  has  meant  that  features  are  often  out-of-date  by  the  time 
the  standard  is  complete.  This  causes  pressure  for  de  facto  standards  to  be  ratified  without  lengthy 
evaluation.  One  approach  to  solving  the  problem  would  be  to  concentrate  on  encapsulating  current 
practice  which  could  be  standardised  more  quickly.  The  alternative  is  to  make  a  new  standard 
progressive  in  all  areas  so  that  it  is  still  timely  ^ter  it  appears. 

Existing  standards  have  tended  to  be  a  mixture  of  current  practice  and  progressive  features  and 
concepts.  This  means  that  standardisation  takes  a  long  time  and  some  features  are  out  of  date  when 
the  standard  appears. 

6)  A  single  reference  model  would  have  expedited  current  standard  activities  by  a 
significant  amount 

A  major  cause  of  long  timescales  has  been  the  lack  of  a  Reference  Model  into  which  the  various 
standards  fit  A  framework  for  new  activities  must  be  agreed  in  some  detail  or  the  same  problem 
will  occur  in  the  next  generation  of  standards. 

7)  Problems  with  text 

It  has  become  increasingly  clear  that  the  text  model  adopted  by  the  current  generation  of  computer 
graphics  standards  is  inadequate,  and  is  also  incompatible  with  the  work  done  within  SC  13.  Thus, 
as  SC24  is  not  the  correct  place  to  develop  a  new  text  model,  future  graphics  standards  should 
integrate  the  work  done  on  text  within  SC  18. 

8)  Deficiencies  with  graphics  input 

The  Input  Model  adopted  by  GKS,  GKS-3D,  and  PHIGS  is  inadequate  to  specify  quality  user 
mtefaces.  and  development  of  a  more  powerful  model  is  required. 
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2^  Trends 

There  was  consensus  on  the  following  points: 

1)  Windowing  technology  cannot  be  ignored 

The  current  standards  are  already  being  used  in  a  windowing  environment.  The  trend  is  for 
computer  graphics  to  be  used  mainly  in  windowing  environments  in  the  future.  The  windowing 
system  will  make  demands  on  the  graphics  system  and  will  constrain  what  is  allowed  in  the 
g^phics  systeixL 

There  is  an  urgent  need  for  some  windowing  facilities  to  be  included  in  the  current  generation  of 
standards.  The  next  generation  of  standards  must  include  windowing  management. 

2)  Integration  with  standards  in  other  areas  has  become  essential 

The  first  generation  of  standardisation  assumed  that  computer  graphics  was  responsible  for  all  the 
output  to  a  device  and  did  not  need  to  interface  with  other  standards.  Today,  graphics  is  being  used 
in  a  distributed  environment  with  multiple  windows  and  shared  devices.  Furthermore,  we  have 
seen  the  increasing  need  for  documents  and  displays  involving  multiple  media,  such  as  integrated 
text  and  graphics.  This  means  that  computer  graphics  has  to  be  more  aware  of  other  standards  and 
be  able  to  coexist  with  them. 

3)  Domain  specific  standards  are  becoming  more  necessary 

The  use  of  computer  graphics  is  expanding  into  new  areas.  This  has  meant  that  it  is  less  likely  that 
one  standard  will  be  appropriate  across  all  application  areas  to  be  possible.  Users  will  demand  what 
is  obtainable. 

4)  Increase  in  the  use  of  graphics 

The  use  of  computer  graphics  has  become  pervasive,  with  graphics  incorporated  in  almost  all 
application  areas.  The  resulting  increase  in  user  population  will  make  standards  more  important  in 
the  future. 

5)  Influence  of  de  facto  "standards”  on  our  work 

The  trend  towards  the  use  of  workstations  in  a  heterogeneous  distributed  environment  has 
increased  the  drive  towards  de  facto  "standards"  available  on  a  range  of  equipment  The  pressure  to 
formalise  such  useful  standards  will  increase  as  the  user  population  wishes  to  access  such  systems 
and  wishes  to  insure  that  implementations  conform  to  such  "standards." 
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3.  Possible  ways  forward 

To  find  out  how  best  to  proceed  with  the  SC24  work,  several  alternate  potential  processes  were 
developed.  These  options  were  then  judged  by  the  following  four  criteria: 


•  time  required 

•  quality  of  results 

•  sta^ng  required 

•  risks 


3.1  The  seven  options  considered 
Option  1  •  option,  see  SC24  N  1 1 1 

produce  a  Basic  Reference  Model  by  the  1989  SC24  meeting; 

-  all  work  not  at  DIS  stage  by  the  1989  SC24  meeting  will  be  suspended; 
completion  of  the  CGM  ad^da  and  CGI  by  the  1989  meeting  should  be  encouraged; 
no  new  project  will  progress  to  DP  before  the  Basic  Reference  Model  is  developed; 

a)  acce^  no  new  work  items  at  ail; 

b)  accept  and  work  on  new  work  items  in  par^lel; 

as  part  of  their  revision  cycle,  standards  will  be  reviewed  in  light  of  the  Basic 
Reference  Model 

work  on  the  Basic  Reference  Model  could  be  viewed  as  the  first  step  in,  and 
prerequisite  for,  the  GKS  revision  processs; 

Option  2  -  see  output  document  from  this  meeting  entitled  "Component  Process  for  Development 
of  Standards" 

start  work  on  Component/Framework  (CFW)  project; 

ail  work  not  at  DIS  stage  by  the  1989  SC24  meeting  will  be  restuctured  using  the  CFW 
model  and/or  a  new  generation  of  standards  could  be  produced; 
as  part  of  their  revision  cycle,  standards  will  be  reviewed  in  light  of  the  Basic 
Reference  Model; 

-  kernel  components  exist,  but  not  necessarily  a  kernel  framework; 

NWI  could  be  accepted  and  would  be  related  to  the  CFW  model 

Option  3  -  Improve  existing  procedures  based  on  lessons  learned 
focus  on  the  GKS  review  and  CGI  completion; 

Alternatives  for  Reference  Model  work: 

a)  no  new  Reference  Model  woiit; 

b)  address  Reference  Model  issues  during  reviews; 
continue  CGM  addenda  work; 

process  NWI’s  as  usual; 

Option  4  •  Suspend  all  work  until  Reference  Model  DIS 
suspend  all  work  not  now  at  DIS  stage; 
concentrate  on  the  Reference  Model  work; 
approve  no  New  Work  Items  until  Reference  Model  DIS; 

after  having  developed  a  complete  Reference  Model,  define  a  second  generation  of 
graphics  standards. 

Option  5  -  Go  on  in  the  usual  way  and  disregard  all  the  lessons  learned  from  the  past 
Option  6  -  Abandon  graphics  standardisation  development 
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3.2  Evaluation  of  the  options 

The  SWG  split  into  three  sub^ups  each  of  which  judged  two  of  the  options  (it  was  assumed  that 
Option  6  could  be  assessed  without  further  discussion).  Besides  the  few  criteria  given  above  (time 
required,  quality  of  results,  staf&ng  required,  and  risks)  several  other  considerations  influenced  the 
ev^uadon  of  the  options: 

•  possible  loss  of  people/effort 

•  possible  loss  of  credibility 

•  need  to  have  a  Basic  Reference  Model  or  a  Component  Framework 

•  need  to  interwork  with  other  standards 


Table  3. 1  gives  an  overall  assessment  of  each  option  against  the  major  criteria. 


CRITERIA 

Options 

Time 

Quality 

Staffing 

— 

Risks 

1 

6 

7 

7 

8 

2 

8 

7 

7 

5 

3 

6 

5 

5 

8 

4 

2 

8 

10-2 

3 

5 

5 

4 

4 

2 

6 

* 

* 

10 

7 

8 

2 

9 

3 

Table  3*1  Assessment  of  options 


Having  discussed  and  assessed  the  seven  options,  the  SWG  believed  that  options  1  and  2  were  the 
most  r^isdc  ways  to  proceed,  with  opdon  3  as  a  rather  poor  fallback  option.  It  was  believed  that 
some  strategy  based  on  a  combination  of  1  and  2  might  produce  a  superior  option  to  all  seven 
examined.  Therefore,  the  SWG  urges  SC24  to  adopt  an  approach  for  future  work  based  on  a 
synthesis  of  the  best  features  from  these  two  options. 
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Comments  on  the  options  rejected  were: 

Option  3  (Improve  Existing  Procedures) 

The  major  advantages  to  this  approach  would  be  continuity,  the  ability  to  respond  to  NWI  quickly, 
and  production  of  compatible  standards. 

The  major  disadvantages  were : 

1)  Experience  has  shown  that  the  cunent  method  of  generating  standards  is  a  ve^  long  process. 

2)  It  is  difficult  to  get  effort  into  Reference  Model  Work  while  it  is  seen  as  a  peripheral  activity. 

3)  Woric  in  the  Reference  Model  area  will  tend  to  be  located  with  the  Work  Items  leading  to 
incompatible  reference  models  between  standards. 

4)  It  is  uidikely  that  the  cunent  approach  will  produce  a  set  of  standards  that  easily  fit  into  a 
distributed  or  rendering  environment 

5)  JTCl  has  requested  work  on  a  Reference  Model  This  approach  is  unlikely  to  satisfy  them. 

6)  The  GKS  Review  is  unlikely  to  attract  CGM  and  PHIGS  experts. 

7)  It  will  not  put  any  deadlines  on  CGI  and  the  work  is  likely  to  extend. 


Option  4  (Stop  all  work  until  complete  Reference  Model  produced) 

The  advantage  of  this  approach  was  the  possibility  of  producing  better  quality  results  than  other 
options.  However,  there  was  some  concern  that  ptxxlucing  a  reference  model  in  a  vacuum  with  no 
parallel  practical  work  might  detract  from  the  quality,  resulting  in  no  better  quality  than  Options  1  or 


The  major  advantages  were; 

1)  It  is  believed  that  the  SC  would  lose  about  a  third  of  the  existing  staff  and  that  it  would  be 
difficult  to  get  them  back  to  standards  work  after  the  moratorium. 

2)  It  would  have  a  negative  effect  on  both  countries  and  constituencies  which  would  impact  the 
credibility  of  the  SC. 

3)  By  insisting  on  a  full  Reference  Model  before  work  would  restart,  would  cause  at  least  a  2  year 
delay. 

4)  An  over-rapid  development  of  a  complete  Reference  Model  might  produce  a  flawed  product. 

5)  Work  would  continue  on  de  facto  standards  inside  ISO  and  in  other  SCs.  This  would  have  an 
adverse  effect  when  work  is  restarted. 

Option  5  (Business  as  usual) 

The  SWG  was  very  concerned  with  applying  past  techniques  to  future  work.  Current  SCI-i 

methods  are  close  to  breakdown  and  not  capable  of  meeting  future  needs. 

In  the  GKS  Review,  either  minor  corrections  would  be  made  or  a  new  version  based  on  a  revised 

GKS  Reference  Model.  Using  current  procedures,  it  is  impossible  to  judge  which  of  those 

approaches  would  be  adopted. 

Additional  disadvantages: 

1)  Much  effort  is  wasted  due  to  the  fragmentation  of  the  work  and  the  continual  need  to  re-assess 
each  work  item  due  to  lack  of  future  planning  and  early  consensus  on  the  goals.  Consequently, 
schedules  are  very  uncertain. 

2)  Results  are  poor  due  to  lack  of  integration  and  incompatability  of  concepts.  Consequently 
leverage  in  the  maricetplace  is  poor. 

3)  Current  process  strains  relations  between  delegations  due  to  incompatability  of  objectives. 

Option  7  (Rubber  stamp  de  facto  standards) 

This  option  does  have  several  advantages: 


167 


Towards  a  Five  Year  Plan 


1)  Standards  are  likely  to  be  produced  relatively  quickly  (less  than  2  years). 

2)  Staffing  may  well  be  easier. 

3)  Standards  a^l  already  have  been  implemented  with  a  defined  user  base.  Consequently, 
acceptance  will  be  high. 

The  disadvantages  which  override  the  advantages  are: 

1)  Long  term  acceptance  of  standards  is  jeopardized.  Industry  tends  to  produce  new  systems 
relatively  quickly.  Life  of  individual  standards  will  be  short. 

2)  The  quality  of  staff  working  on  standards  will  decrease.  It  will  tend  to  attract  staff  with  a 
narrow  perspective. 

3)  Compatability  of  standards  is  abandoned. 

4)  Standards  will  tend  to  overlap. 

5)  Incompatabilities  are  likely  to  arise  between  the  de  facto  standard  and  its  ISO  equivalent  due  to 
the  different  speeds  of  revision. 

6)  Difficult  to  resjxmd  to  users'  requirements. 

7)  Stability  of  user  environment  will  suffer,  leading  to  increased  costs. 

8)  Consensus  may  be  difficult  to  achieve.  Politics  may  play  a  greater  part  There  could  even  be 
legal  problems. 

9)  The  current  set  of  standards  would  be  abandoned. 
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4.  Recommended  5  year  plan 

4.1  Projects  likely  to  be  affected  by  1989  "cutofT 

Under  the  two  options  for  significant  procedural  changes  proposed  by  the  SWG  on  Future 
Planning,  mid  -  1989  forms  a  milestone  in  the  processing  of  SC24  projects.  Those  projects  which 
are  not  at  DIS  or  DAD  stage  would  either  be  suspended  or  restructured.  It  is  anticipated  that  the 
following  semantic  defmition  projects  will  be  advanced  enough  and  will  not  be  affect^: 

CGI 

CGM  Addendum  1 
(PfflGS) 

(GKS-3D) 

The  following  existing  and  new  proposed  projects  will  likely  be  affected: 

CGM  Addendum  2 
CGM  Addendum  3 
PHIGS  + 

Windows 

Imaging 

Reviews  (GKS,  CGM,  PHIGS,  CGI,  ...) 

Basic  Reference  model  work  will  receive  increased  emphasis  under  both  options,  and  will  not  be 
affected  by  the  deadline. 

The  SWG  recommends  that  there  should  be  no  effect  on  LAB  and  Validation  and  Testing  work. 
There  are  two  options  for  Registration: 

-  no  effect: 

•  new  proposals  are  not  accepted  for  some  time. 


4.2  Structure  of  Work  prior  to  the  1989  SC24  meeting. 

Both  options  for  procedural  changes  affect  the  structure  of  work  for  new  and  uncompleted  projects. 
The  implications  for  the  affected  projects  listed  above  are  given  in  the  next  two  sections.  In  both 
cases,  completion  of  the  CGI  and  CGM  Addenda  is  encouraged.  It  is  felt  that  the  CGI  and  CGM 
Addendum  I  will  have  progressed  far  enough  (DIS  /  DAD)  before  the  cutoff  date. 

Option  1:  Up  to  and  after  the  1989  SC24  meeting,  work  on  a  Basic  Reference 
Model  (BRM)  proceeds. 

1)  Work  not  at  DIS  /  DAD;  experts  working  on  projects  are  urged  to  estimate  carefully  the  chances 
of  reaching  the  DIS  stage  tefore  the  cutoff  date. 

2)  Review;  review  of  GKS,  CGM,  PHIGS,  CGI,  etc.  will  commence  when  they  are  considered 
for  review. 

3)  NWI:  CGM  Addendum  3,  PHIGS  +,  Windowing,  Imaging;  two  options  are  identified: 

a)  work  allowed,  but  not  b^ond  WD,  until  BRM  finished; 

b)  no  work  until  BRM  finished. 

The  majority  felt  that  the  first  was  better  -  as  it  would  allow  the  development  of  NWI  work,  limited 
to  WD  stage. 
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Option  2:  work  on  a  Basic  Reference  Model  •  defining  component  types  and 
frameworks  •  proceeds  up  to  and  after  the  1989  SC24  meeting. 

1)  work  not  at  DIS  /  DAO:  experts  working  on  projects  are  urged  to  estimate  carefully  the  chances 
of  reaching  the  DIS  stage  tefore  the  cutoff  date. 

2)  reviews:  review  of  GKS,  CGM,  PHIGS,  CGI, will  comence  when  they  are  considered  for 
review.  The  effect  of  the  new  components/framework  (CFW)  process  is  not  yet  determined. 

3)  NWI:  CGM  Addendum  3,  PHIGS  +,  Windowing,  Imaging;  could  proceed  under  the  new 
CFW;  this  would  probably  mean  some  delays  while  the  components  of  the  CFW  were 
advanced  sufficiently  and  the  NWI  were  given  frameworks. 

4J  Structuring  work  after  1989 

With  the  adoption  of  either  option  1  or  option  2,  we  must  consider  how  the  work  of  SC24  would 
be  organised  after  the  1989  meeting.  There  are  two  obvious  alternative  ways  to  proceed.  Under  the 
first  option,  work  would  continue  to  b-e  organised  according  to  the  first  generation  standards  where 
possible,  with  additional  rapporteur  groups  added  to  accomodate  the  new  work  areas. 

Under  the  second  option,  work  would  be  re-organised  according  to  a  component  /  framework 
decomposition.  First  generation  standard  revision  would  be  carried  out  by  "mapping "  these 
standard  into  the  new  framework. 

Figure  4.1  illustrates  a  likely  progression  of  work  under  option  I.  Review  of  each  standard  would 
start  approximately  four  yean  after  it  became  an  IS.  During  this  review,  each  standard  would  be 
restructured  into  a  framework  in  accordance  with  the  new  Basic  Reference  Model.  Reference  Model 
^rk  to  develop  component  models  would  continue  after  1989.  [CGI  review  is’ not  illustrated  since 
it  would  begin  beyond  the  five  year  period  considered  here]. 
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Figure  4*1  Progression  organised  according  to  Current  Work 
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Figure  4.2  illustrates  one  possible  progression  of  SC24  work  under  the  second  option.  Reference 
Model  work  would  continue  developing  at  least  the  core  components.  Some  components  ••  such  as 
those  involved  with  imaging  or  windowing  ~  might  be  developed  by  separate  rapporteur  groups, 
but  su^cient  interesting  work  must  remain  within  the  Reference  Model  Rapporteur  Group  to  attract 
qualified  experts  to  the  work.  New  work  would  be  developed  as  appropriate. 
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Figure  4-2  Progression  organized  according  to  Component/Framework  Model 

4.4  Extensibility 

Future  SC24  standards  must  consider  requirements  for  user-defined  extensibility. 

4.5  Management  of  work 
Management  of  work  would  be  at  the  SC24  level. 
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DOCUMENTS  FROM  BLAKENEY  METAFILE  RG  MEETING 
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Minutes  of  IS0/ISC/JTCI/SC24/WG1  CG£M  Meeting 


l8th  April  1988 

Blakenev  Hotel.  Norfolk,  England 


Present 


E  Moeller,  L  Henderson,  W  Brandenburg.  A  Francis,  A  Mumford,  0  Arnold  (part 
of  day) 

1.  Welcome 

E  Moeller  thanked  D  Arnold  on  behalf  of  the  group  for  organising  the 

meeting  in  such  pleasant  surroundings. 

2.  Report  of  Rapporteur 

E  Moeller  thanked  A  Mumford  for  preparing  Addendum  1  for  the  SC24 
meeting. 

Addendum  2  was  produced  later  than  had  been  hoped  and  SC2tf  have  not 
put  this  out  for  ballot. 

D  Arnold  to  handle  WG3  mailing. 

3.  Report  on  Special  Working  Group  Meeting 

D.  Arnold  reported  on  this  meeting.  Recommendation  2  from  the  meeting 
proposed  that  SC24  should  have  DIS  or  DAD  text  ready  for  ballot  by 
the  end  of  the  SC24  1989  meeting.  If  not  the  work  will  be  suspended 
or  restructured. 

Addendum  2  was  discussed  in  this  light.  There  was  concern  t.nat  the 
document  may  not  meet  this  deadline. 

Addendum  3  was  not  discussed  in  detail.  The  need  for  the  work  was 
discussed  implicitly. 

The  SWC  .had  discussed  c.he  way  that  future  work  mig.ht  progress.  The 
wor.k  may  be  split  up  into  groups  which  discuss  components  of 
standards . 

^  •  Tucson  meeting  -  straceg:/  for  addendum  processi.ng  -  freouencv  of 
meetings 

The  meeting  at  Tucson  for  CGM  work  is  4  days.  It  is  hoped  that 
editing  work  and  CGI  liaison  may  continue  till  the  Tuesday  of  the 
second  week. 

The  frequency  of  meetings  was  discussed.  The  balance  between  the 
different  projects,  c.he  amount  of  work,  good  representation  causes 
problems. 

An  interim  meeting  on  all  3  addenda  night  attract  good  attendance.  A 
week  long  meeting  possibly  in  early  1989  maybe  in  the  U.S. 
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Possible  schedule  -  tighcesc 


mid  September 
end  September 
end  December 
end  Feb/s tart  March 


document  out 
distributed 
comments  in 
editing  meeting 


This  is  the  tightest  schedule  possible.  The  advantages  and 
disadvantages  of  producing  a  draft  out  of  an  interim  meeting  were 
disciissed.  A  March  meeting  seems  favourite. 


5-  Discussion  of  Comments  to  Addendum  1 


(i)  General 


Relationship  CCl/CCX 

It  is  a  major  problem  that  the  group  do  not  have  the  new  CGI 
document.  It  was  agreed  that  we  would  have  to  accept  t.he 
comments  regarding  the  current  proposals  e.g.  Austrian  comments 
7  (clarification)  for  this  meeting. 


(a)  Austrian  Comment 

Austrian  comment  re  UPDATE  -  do  we  need  to  explain  t.he 
MAKE  PICTURE  CURRENT/ UPDATE  differences.  A  clarificatic 
note  may  be  required.  An  alternative  is  to  make  UPDA-- 
just  UPDATE  'perform' . 

Agreed  it  is  desirable  to  remove  redundancy. 
Alternatives: 

a.  UPDATE  only  allowed  for  'perform' 

b.  remove  MAKE  PICTURE  CURRENT 

There  was  discussion  on  CGI  liaison.  There  is  need  for 
liaison  at  the  CGEM  meeting  at  Tucson.  This  is  mainly 
for  technical  assistance.  It  is  .hoped  that  a  .number  of 
delegations  could  have  experts  available. 

It  was  agreed  we  wished  to  be  close  to  CGI  and  chat  we 
would  have  an  element  for  update  wit.h  'perform'  .  CGI  has 
access  to  the  flag  'new  frame  necessary  at  update'. 

UPDATE  .'-’CSTPONE!  maps  to  MAKE  .PICTURE  CURRE.VT 

UPDATE  (PERFORM)  -  it  is  proposed  t.hac  a  new  element 
PERFORM  DEFERRED  ACTIONS  is  included  in  Addendum  1  tc 
replace  the  current  'UPDATE. 

In  IMPLICIT  SEGMENT  REGENERATION  .MODE  need  to  describe 
t.he  actions  wnic.h  can  be  deferred  (page  29)- 

A  paper  is  to  be  written  on  t.he  update  issue. 

(b)  REGION  OPEN/CLOSE  to  be  removed  as  in  CGI. 

(c)  Use  i.hheritamce  filter  for  REOPEN  -  in  CGI  t.his  only 
applies  CO  COPY.  Agreed  we  should  do  same  as  CGI. 
Believe  chat  effect  can  be  ac.hieved  with  SAVE  and  RESTORE 
attributes . 
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Discussion  on  COPY.  DOES  COPY  need  co  be  i-ncluded  in  i.ne 
aiecafile?  Is  ic  jusc  for  Global  Segments.  It  depends 
where  the  COM  is  in  the  CGI  pipeline.  Metafiles  would  be 
larger  if  COPY  is  not  there.  Agreed  that  COPY  should  be 
retained. 

CSSR  Comments 

CGI  has  to  be  technically  stable  now  if  it  is  to  meet  the 
deadline  (assuaing  SC24  accepts  SWG  recommendations). 

Shotild  the  2  addendxio  be  merged?  Straw  vote  -  3  ‘^0  2 
ABSTENTIONS. 

Technical  comment  4  -  description  on  segments  needed. 

Technical  comment  8  -  REDRAW  SEGMENT  is  missing  -  to  be 
included. 

UK  Comments 

These  were  discussed  in  full  while  A  Francis  was  present. 

1.  Re  MODIFY  FONT/CHARACTER  SET  LIST.  These  were 
included  at  Valbonne  because  there  is  no  start 
index  for  the  lists.  There  was  concern  that  a  high 
numbered  font  might  be  used  in  GXS  and  might  cause 
a  sparse  font  list. 

It  was  suggested  that  the  GKS  font  number  might 
have  a  high  value  but  that  the  registered  name 
would  be  included  as  the  next  font  in  t.he  font 
list. 

The  use  of  the  modify  prevents  t.he  generator 
writing  the  descriptor  last. 

Straw  vote 

3  in  favour  of  removing  t.he  elements 
2  against 

2 .  SEGMENT  PRIORITf 

Integer  or  real  -  agreed  t.hat  should  follow  CGI. 
Whatever  decision  t.hat  is. 

Is  CGI  Part  6  stable  enough  for  inclusion  of  PIXEL 
ARRAY  and  DRAWING  MODE? 

If  still  within  CGI  t.hen  we  will  leave  t.hen  in. 

US  comment  suggests  adding  local  colour  precision 
this  was  agreed. 

Should  there  be  a  compressed  encoding  for  PI.XEL 
ARRAY? 

4.  Segment  elements  should  be  split  to  segment  control 
and  attributes.  At  Valbonne  t.hey  were  joined  co 
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allow  jusc  one  class  in  “he  binary  encoding.  I: 
was  agreed  to  separate  these. 

5.  DRAWING  MODE  -  should  use  enumerated  types  -  follow 
CGI. 

6.  UPDATE  -  discussed. 

7.  DEVICE  VPORT  SPEC  UNITS  -  should  have  same  default 
as  GKS  -  follow  CGI. 

8.  Elements  in  Figure  Open  State  -  CGI  allows  more 
flexibility  than  CCS!  regarding  the  appearance  of 
events  in  states  such  as  text  open. 

Agreed  that  we  should  maintain  the  C&M  philosophy 
and  make  Figure  Open  Similar  to  Text  Open. 

Allow  the  fill  attributes  as  well. 

9.  SAVE  PRIMITIVE  ATTRIBUTES  saves  all  attributes  but 
INHERITANCE  FILTER  allows  selectivity.  Needs  to  be 
consistent.  Need  to  check  current  CGI  text. 

Metafile  Categories  and  Element  Sets 

It  is  necessary  to  complete  the  following  table: 


Element  Set 

Category 

cgm 

cgmaddl 

gksm 

DRAWING  SET 

X 

1 

DRAWING  PLUS  CONTROL 

X 

GKSMO 

X 

I 


France  have  suggested  a  category  for  static  structured 
pictures . 

There  is  an  individual  US  position  suggesti.ng  a  static  picture 
plus  global  segments  and  the  new  primitives. 

The  US  have  suggested  that  there  should  be  an  element  set  fcr 
GKSM  (as  well  as  GKSMO)  .  Should  the  shorthand  have  a  differe.nt 
name? 

I  was  agreed  that  t.here  was  no  need  for  a  GKSMO  category.  Ic 
was  also  agreed  tnat  the  GKSMO  element  list  would  remai.-. . 
Franca  have  suggested  5  categories.  It  was  felt  that  1  were 
possible  via  category  or  shorthand  now.  The  static  image  is 
the  current  CGM  plus  the  element  list.  It  was  felt  it  could  be 
e.xtended  for  structures  as  global  segments  but  just  used  as  a 
symbol  library.  i.e.  A  static  picture  plus  structures  which 
cannot  be  handled  dynamically  plus  other  additional  eleme.ncs. 
The  French  proposal  suggests  chat  this  structured  image  cou-c 
also  be  modified  using  bundle  table  modifications. 
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The  French  proposal  for  Che  structured  iaage  would  be  in  the 
GKSM  category.  The  static  structured  picture  would  be  i.n  t.he 
CGMAOOl  category.  Both  these  oay  be  useful  as  symbol 
libraries . 

There  was  uncertainty  as  to  why  soae  of  the  ocher  elements  are 
omitted.  It  is  necessary  to  have  some  more  clarificaticn. 

It  was  agreed  that  few  cacefories  and  more  element  lists  were 
required. 

All  categories  therefore  include  structures  and  the  subsets  are 
element  lists  which  conform  to  a  category. 

Defer  decision  on  Tucson  recommendation  until  Tuesday. 

France 

France  note  CLIP  INDICATOR  and  CLIP  RECTANGLE  have  been  oade  a 
single  function.  This  is  incompatible  with  CGM  -  raise  with 
CGI  group. 

Pixel  array  is  in  Part  6  of  CGI  which  implies  a  different 
encoding  class  from  output  primitives  as  used  in  Addendum  1  for 
this  element. 

France  ask  for  clarification  of  relationship  between  GKS  and 
CGM.  The  mapping  will  be  included.  It  was  agreed  that  t.he 
precisions  do  not  need  to  be  passed  to  the  application  layer. 

Germany 

Tl-2  to  Tl-4  -  agreed  to  move  DP.  c.hange  description  of  VS?  and 
add  VSU  to  be  closer  to  CGI. 

United  States 

Discussion  (based  on  U.S.  T8)  on  the  rigorous  structure  to  a 
metafile.  There  has  been  a  move  of  VDC  EXTENT.  This  comment 
suggests  the  majority  of  Picture  Descriptor  elements  should  be 
In  other  states.  This  is  not  justified  under  the  sccte 
and  goals  of  t.he  addendum  work. 

Page  1-7  T25 

REOPEN  should  be  a  delimiter  element  -  agree. 

Page  1-7  T27 

REDRAW  .ALL  SEGS  -  missing  -  agree 
T26  -  agree  change 

TIO  -  agree,  as  BSI  comment  addressed  earlier 
Til  -  agree 

T12  -  agree  -  error  in  text 

T13  -  agree  -  add  a  note  to  the  table  i.ndicating  Metafile 
Closed  State  can  exist  with  BEGIN  METAFILE  being  the  only 
element  allowed. 
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T19  -  document  should  follow  "null  value  rule"  e.g-  invisible, 
visible  -  agreed  this  should  be  done,  also  ensure  that  CGI  is 
the  same. 

T20  -  as  T19 

T21  -  agree  -  modify  table. 

T22  *  agreed  -  see  earlier  discussion. 

TE52  ■*  agreed  -  wording  should  be  changed. 

TE63  *■  transformation  matrix  for  SEC  TRANS  is  different  in  CGI 
-  agreed  to  edit. 

Japan  T5  -  copy  segment  as  US  comment  -  agree 

USA/Tl  General  comment  on  errors  -  most  of  this  is  related  to 
the  CGI  text  copying  for  this  draft. 

USA/T9  "  does  the  grammar  imply  an  order  which  is  not  in  the 
functional  description.  Ordering  is  sensible  in  the  Metafile 
Descriptor.  This  is  not  the  case  in  the  CGM  IS  text. 

Geraany/Tl  suggests  the  Met  Elen  List  and  Met  Category  should 
appear  before  first  global  segment. 

Agree  in  principle  but  need  to  decide  the  way  to  do  this. 

Would  version  2  metafiles  which  are  of  category  'cgm'  (default) 
also  have  this  implied  category. 
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iQth  April  1988 


Present 


E  Moeller,  L  Henderson.  A  Mumford.  T  Hewitt,  W  Brandenburg,  D  Arnold  (part 
of  day) 

1.  Addendum  1  -  Continuation  of  Technical  Work 
Category  and  Eleaent  Seta 
Austria 

Comment  Al/Tl  refers  to  element  sets  and  metafile  categories  -  it  was 
agreed  that  we  now  had  a  clearer  define'  tion  and  the  text  would  be 
improved. 

It  was  agreed  we  have  3  categories  'cgm'.  'cgmaddl'.  ’gksm’. 

This  comment  also  relates  to  the  discussion  the  day  before  on  t.^e 
French  and  a  US  individual  position. 

Do  we  wish  to  have  further  element  sets?  There  was  some  syopac.hy 
with  the  idea  of  a  structured  static  picture  to  allow  the  new 
primitives  to-be  used  together  with  global  segments.  This  gives  the 
ability  to  have  a  symbol  library  for  a  static  picture. 

It  wais  agreed  that  clarification  and  further  discussion  at  Tucson  was 
required . 

It  was  noted  that  making  the  category  and  element  list  orthongonal 
results  in  a  large  number  of  'profiles'.  Should  we  allow  all 
possible  combinations  of  element  class  and  category? 

It  may  be  useful  to  indicate  in  the  standard  which  'profiles'  are 
particularly  useful. 

CGI  Related  Issues 

D  Arnold  clarified  the  situation  of  t.he  CGI  document.  Cocusent  cut 
April/ May.  Tucson  will  be  first  to  pass  over  comments.  Aug,  Sept 
editing  meeting  to  produce  second  DP  which  will  be  out  by  end  cf 
year. 

Pixel  array  has  been  redefined  as  a  bitblt  operation.  This  may 
therefore  not  be  relevant  for  .Addendum  1  as  it  is  no  longer  an  output 
primitive. 

Most  of  major  issues  have  been  addressed  by  t.he  CGI  group. 

GKS  Related  Issues 

A/T16  -  request  for  description  of  mapping  COPY/ INSERT  to  be  changed 
to  be  as  GKS. 

It  was  agreed  that  GKS  COPY  and  INSERT  should  be  mapped  as  .Annex  £ 
and  not  be  COPY  SEGME.NT.  iq. 


V>l 


Other  Coiiunencs 


United  States 

US/T5  Scaling  Mode  and  Device  Viewpoint.  It  was  agreed  that  the  te.xt 
needs  to  be  changed. 

US/T7  RENAME  and  DELETE  should  not  be  in  global  segments.  It  was 
agreed  at  Valbonne  that  DELETE  should  not  be  allowed.  RENAME  was  not 
listed  in  the  Valbonne  minutes.  Agreed  that  RENAME  does  not  cause 
problems,  but  the  same  is  true  for  DELETE  if  the  MD  is  progressed 
sequentially.  There  was  no  use  seen  for  the  elements  in  GS  state. 
Agreed  with  Valbonne  decision  on  DELETE  and  extend  to  RENAME  as  US/T7 
coouBenc . 

Tl4  -  agree  -  Annex  D  to  be  extended. 

T15  -  DEVICE  VIEWPORT  default  should  be  (0.0)  (1.1)  not  i.d.  Need  to 
check  CGI. 

Tl6  ”  PICK  ID  default  -  agree,  as  CGI 

T17  -  agreed  to  make  edit.  Should  the  grammar  be  part  cf  t.be 
standard  if  we  are  defining  conformance  via  the  grammar. 

This  may  be  a  problem  for  backwards  compatibility  with  CGM  versicn  1. 

Tl8  -  Annex  E  needs  paragraph  re  generating  correct  CGM  font 
information  -  agreed. 

T23  -  END  SEGMENT  is  not  allowed  in  MD  -  needs  to  be. 

TEl  -  no  we  cannot  define  new  data  types  because  of  backwards 
compatibility.  Maybe  an  amendment? 

Till  -  request  for  text  an  the  differences  between  pictures  and 
'frames'.  It  was  agreed  this  would  be  useful.  No  support  for  adding 
information  on  capcuri.ng  frames  in  WI3S. 

TE14  -  new  state  Defaults  Replacement  (DR) . 

Til6  -  (also  Austria)  need  to  rewrite  text  for  .MAXIMU.''^  VCC  EXTENT. 

2 .  Parts  2-^ 

Mainly  relate  to  Part  1  changes.  Decided  to  leave  this. 

Amendme.nts  to  CGM  is  Text 

It  was  agreed  that  amendments  would  be  useful.  These  are  to  be 
listed  by  Tucson  and  t.ne  procedure  for  fcrmalisi.ng  t.nese  sorted  out 
by  SC2<i. 

Addendum  ? 

As  a  minimum  we  need  to  ensure  t.hat  t.he  Tucson  meeting  makes  a 
decision  on  the  work.  It  was  suggested  that  one  option  might  be  for 
SC24  could  recognise  the  value  of  t.he  work.  The  components  of  t.be 
work  could  be  working  on  in  SC24. 
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It  was  agreed  chat  there  was  interest  in  the  work  progressing.  The 
SC24  deadline  causes  problems  for  the  split  of  the  work.  The  US  has 
people  interested  in  the  work.  There  are  problems  for  the  metafile 
group  in  discussing  new  functionality  for  graphics  standards.  There 
is  a  need  to  discuss  these  elements  across  application  interfaces  and 
metafiles  etc. 

Group  to  recommend  to  SC24  that  the  work  is  interesting  and  relevant. 
Although  the  group  is  aware  of  the  SWC  recommendations  the  group 
feels  that  this  work  should  be  progressed  in  some  form  at  SC24. 

5.  Addendum  2 


Need  to  sort  out  the  scope  and  purpose  chat  can  be  achieved  given  the 
SWG  recommendations  on  timescale. 

SC24  has  approved  GKS-3D  extension.  The  London  meeting  found  chat  it 
was  straightforward  to  use  global  segments  to  extend  t.he 
functionality  cowards  PKIGS. 

E  Moeller  noted  the  good  quality  of  the  document  and  thanked  T 
Hewitt.  Terry  noted  that  the  document  was  a  team  effort. 

The  timescale  was  such  that  no  comments  are  available.  There  are 
therefore  no  national  comments. 

There  was  clarification  of  the  technicatl  reasons  surrounding  the 
current  draft. 

GKS-3D  metafile  is  stored  NBC 


1 

WC 

Normalization  Trans 

metafile  —  1 

NDC 

View  Modelling 

1 

.NPC 

Workstation  Trans 

1 

DCsVDC 

PHIGS 


Polyline 


.\PI 


I  Screen 


To  access  a  workstation  in  PHIGS  -  open  it  and 
metafile  output  workstation  can  be  defined, 
replaced  what  is  written  on  c.he  metafile. 


post  structures. 
If  an  element 
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Functions  are  written  to  the  archiver  explicitly  and  this  is 
therefore  cleaner  than  a  metafile. 

If  COM  is  written  below  API  then  need  to  store  EXECUTIVE  STRUCTURE, 
if  below  traverser  then  this  is  a  flattened  structure.  In  Addendum  2 
theses  are  categories  PHIGS  and  PHICSMO.  The  PHIGS  category  could  be 
used  as  an  archiver. 

There  are  only  a  few  elements  need  to  go  from  PHIGSMO  to  PHIGS. 

The  metafile  workstation  has  to  handle  continuous  traversal. 

PHIGS  already  has  an  archive  file  -  is  duplication  a  good  idea.  The 
PHIGS  archive  clear  text  former  is  not  the  same  the  clear  text 
encoding  of  CGM. 

There  was  some  discussion  on  the  merits  and  problems  of  mixi.-.g  2D  and 
3D  coordinates  in  a  metafile-  All  coordinates  going  to  the 
workstation  will  be  3D.  The  PHIGS  archiver  has  2D  and  3D  coordinates 
because  it  goes  out  and  comes  in  at  the  same  point  in  the  pipeline. 
This  is  not  necessarily  the  case  of  CGM. 

The  archiver  is  not  adequate  for  a  hard  copy  capture  mechanism.  Tne 
metafile  workstation  is  (probably)  too  flexible  for  this.  Need  t:: 
open,  post  and  close. 

The  archive  file  format  is  based  on  the  CGM.  The  need  for  a 
consistent  line  format  across  the  API  standards  is  important. 

Should  we  be  using  the  PHIGS  archive  file  as  the  basis  for  work? 
Should  there  be  character  and  clear  text  encoding  for  the  archive? 
file. 

T  Hewitt  to  write  an  explanation  of  what  is  in  the  current  document. 

The  decisions  of  Egham  and  Valbonne  to  do  at  least  GKS-3D  support 
were  reaffirmed.  It  was  agreed  that  any  f’unctions  now  wit.ndrawn  from 
GKS-3D  and  PHIGS  will  be  removed  from  Addendum  2. 

6 .  Allocation  of  Work 


,  a; 

Addendum  2  description,  scope  and  goals 

'.vTH 

;b) 

UPDATE  clarification 

LH 

(c; 

CGI  questions 

EM 

id) 

Mapping  CGM  Elements  to  GK3  Item  Types 

EM /AM 

■  e ) 

GXS  Grammar 

W3 

ff) 

CGM  Ame.ndments 

LH/AM 

is) 

Statement  for  5C24  on  Addendum  3 

LH 

(h) 

op-codes 

(i) 

Tec.hnical  changes  to  Addendum  2 
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Oo-codes 


The  3SI  have  produced  a  draft  CGI  character  encoding.  They  nave 
suggested  some  changes  on  the  op-code  tables  in  Addendum  1. 

Agreed  to  use  one  class  for  segment  functions  and  that  a  single  class 
should  also  be  used  in  the  binary  encoding. 

SC2/WG8  -  suggested  PICK  ID  should  be  in  the  segment  class  rather 
than  the  attributes.  The  group  felt  that  it  was  more  appropriate  to 
keep  it  with  the  primitive  attribute  elements. 

It  was  agreed  to  move  BEGIN  FIGURE  to  3/3  3/0  and  to  move  the  rest  of 
the  elements  following  that  element. 

The  'device  viewpoint'  data  type  referred  to  by  SC2  has  been 
addressed  by  the  German  technical  comments. 
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CLTPUT  DOCUMENTS 


1.  Minutes 

2.  Addenduta  2  clarification 

3-  Addendum  3  recommendation 

4.  UPDATE  clarification 

5-  Draft  disposition  of  comments 

6.  Amendments  to  IS  text 

7 •  GKSM  Grammar 

8.  Mapping  GKS  Elements  to  item  types 


SC24/u:G^/>J|';r 
SC24  /uoG3 /K)  n 
SC24  /  /  M  I  ^ 

SC24  /ui<Gr3  /  nJ 
SC24/WG3/CGM 
SC24/WG3/CGM 


186 


"  - 


ARCHIVES  AND  METAFILES  -  very  rough  draft 

W.T.  Hewitt 

Introduction 

This  document  will  clarify  the  functionality  supplied  in  CGM  Addenda  2  for 
the  support  of  metatiies  and  archivers,  of  PHIGS.  The  next  sections  describe 
the  current  status  and  intent  of  the  various  documents  involved.  Following 
is  a  discussion  on  the  problems  and  a  list  of  possible  solutions. 

Pertinent  Documents 

DIS  9592-1  PHIGS 

DIS  9592-2  PHIGS  ARCHIVER 

DIS  9593-3  PHIGS  ARCHIVER  -  Clear  Text  Encoding 

IS  3632  CGM 

ISO/IEC/SC24/N19  CGM  Addenda  1  Functional  Specification 
ISO/IEC/SC24/N23  CGM  Addenda  2  Functional  Specification 

PHIGS  and  Archiving 

PHIGS  has  explicit  support  for  Archives  via  functions  such  as  OPEN  ARCHIVE. 
ARCHIVE  STRUCTURE  NETWORKS  etc.  as  specified  in  part  1 .  Parts  2  and  3 
describe  a  file  format  for  the  archiver.  The  application  snapshots  the 
Central  Structure  Store  with  functions  such  as  ARCHIVE  STRUCTURE  NETWORKS  and 
a  copy  of  the  aopropriate  staictures  are  despatched  to  the  file.  While  this 
is  good  and  satisfies  a  large  user  requirement  NO  workstation  deoendant 
information  is  stored,  e.g.  the  view  representations  or  bundle  representations. 
PHIGS  Part  2  The  Archive  File  Format  states: 

0.2  Reasons  for  this  Standard 

The  main  reasons  for  introducing  a  Standard  PHIGS  archive  file  are: 
a)  to  allow  structure  definitions  to  be  stored  in  an  organised  way  on  a 
grapnical  software  system. 

0)  to  facilitate  transfer  of  structure  definitions  between  different 
graonicai  software  systems. 

c)  to  enable  structure  definitions  to  be  transferred  between  different 
comouter  graphic  installations. 

9.8  Relationship  to  othe  Standards 

This  standard  draws  extensively  for  its  model  of  an  archive  file  format  on 
ISC  8632.... 

It  appears  the  intent  is  to  support  metafile  type  functionality!  3ut  if 
exchange  between  sites  etc  is  required  there  should  also  be  a  character 
encoding  and  binary  encodings. 

PHIGS  Metafile 

PH'GS  also  has  a  metafile  workstation  facility.  Again  to  extract  from  PHIGS 
DIS  9592 

4.9  PHIGS  Metafile  Interface 

For  the  purpose  of  long-term  filing  of  graphical  information.  PHIGS  provides 
an  interface  to  file  called  graphical  metafiles.  They  can  be  used  for: 
a)  transporting  grapnical  information  between  systems: 
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b)  transporting  graphical  information  from  one  place  to  another  (for  example 
by  means  of  magnetic  tapes); 

c)  transporting  graphical  information  from  one  graphical  application  to 
another  (for  example,  between  PHJGS  applications  and  applications  using  other 
graphical  standards); 

d)  storing  accompanying  non-graphical  information.. 

The  major  difference  to  the  archive  above  is  that  workstation  dependent 
information  IS  stored  in  the  metafile.  The  standard  does  NOT  explicitly 
exclude  a  metafile  which  can  support  the  stfucture  mechanism.  However 
because  this  interface  is  a  workstation  if  a  structure  is  being  edited  that 
has  been  posted  to  a  workstation  of  category  MO  many  traversals  will  occur 
and  the  document  gives  no  indication  to  what  to  do  -  whether  to  store  ALL 
versions  of  that  particular  structure,  or  only  the  one  that  was  effective  at 
some  particular  time.  Annex  H  (which  is  NOT  part  of  the  standard)  discusses 
this.  Further  it  is  not  clear  from  PHIGS  where  in  the  pipeline  the  metafile 
information  leaves  and  re-enters.  For  example,  what  happens  when  an 
INTERPRET  ITEM  function  is  actioned  to  handle  a  SET  VIEW  REPRESENTATION? 
Does  it  go  to  ail  open  workstations? 

CGM,  and  CGM  Addenda  1 

Both  of  these  documents  have  the  same  clause  0.2: 

0.2  Reasons  for  this  International  Standard 

The  main  reasons  for  producing  a  standard  computer  graphics  metafile  are; 

a)  to  allow  picture  information  to  be  stored  in  an  organised  way  on  a 
graphical  software  system; 

b)  to  facilitate  the  transfer  of  picture  information  between  different 
graphical  systems: 

c)  to  enable  picture  information  to  be  transferred  between  graphical  devices: 

d)  to  enable  picture  information  to  be  transferred  between  different 
computer  graphics  installations. 

CGM  was  not  sufficient  to  support  GKS  and  hence  the  introduction  of  addenda  1 
CGM  Addenda  2 

This  addenda  was  added  primarily  to  support  GKS-3D.  At  that  time  it  was  very 
iikely  that  namesets  etc  would  be  added  to  GKS-30.  The  implication  of  that 
was  taken  into  account  at  the  London  Meeting.  It  became  clear  at  that  time 
that  by  adding  three  functions  to  the  CGM  a  great  deal  of  subpon  for  PHIGS 
could  be  supolied.  Those  functions  were  EXECUTE  STRUCTURE.  SET  LOCAL 
transform  and  SET  GLOBAL  TRANSFORM.  All  the  other  functions  necessary  to 
suopoa  GKS-3C  and  PHlGS  were  already  m  the  document.  The  addition  of  these 
three  functions  now  enable  the  CGM  A2  to  serve  as  a  support  for; 

a)  The  Workstation  interface  of  PHIGS  (i.e.  a  devices  which  can  support  the 
structuring  features  of  PHIGS)  -  session  capture 

b)  The  Archiver  (no  representation  functions)  -  nearly  picture  capture 

c)  A  dumb  device  driver  for  PHIGS  i.e.  a  device  which  cannot  support 
structures  -  picture  capture. 

Discussion 

Clearly  for  a  PHIGS  implementer  there  is  now  the  choice  of  three  standards  to 
help  him  develop  his  implementation: 
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a)  CGM  for  the  metafile  Workstation 

b)  PHIGS  Archiver  (as  in  9592  PArts  2  and  3) 

c)  CGM  Addendum  2 

The  goafs  of  the  areas  discussed  above  are  so  ciose  that  it  is  natural  to 
bring  them  together.After  ail  GKS-30  and  PHIGS  are  supposed  to  be  part  of  a 
family  of  oompatable  Graphics  standards. 

As  to  the  interfaces.  The  Archive  interface  to  PHIGS  is  good.  The 
functionality  is  well  defined  and  there  are  no  ambiguities,  (if  the  user 
wants  several  copies  of  the  structure  store,  representing  the  status  after 
each  edit  the  user  mus  EXPLICITLY  request  those.  Thus  there  will  be  no 
degradation  of  the  interactive  performance.  The  problem  is  that  the  user 
cannot  get  a  hardcopy,  i.e.  an  archive  with  the  representations;  except  that 
the  following  piece  of  code  is  used; 
open  workstation(hardcopy  device) 
post  structure  network(fred.hardcopydevice) 
ciose  workstation(hardcopy  device) 

The  disadvantage  of  this  functionality  is  that  if  the  user  forgets  the  close 
workstation,  then  the  situation  is  NOT  defined  clearly  and  unambiguously.  I 
think  the  metafile  workstation  type  should  be  removed  from  PHIGS  and  the 
functionality  of  the  archiver  be  extended  to  allow  the  workstation  dependent 
bits  be  addedi  For  example  the  following  instructions  would  be  provided: 
open  archive 

output  structure  network  and  representations  to  archive  (call  this  XYX) 
close  archive 

Conceptually  there  would  be  a  workstation  state  list  in  PHIGS  and  the 
representation  functions  would  set/inquire  those  entries.  The  information  is 
only  written  to  the  archive  when  the  function  XYX  is  called.  The  action  of  XYX 
is; 

1)  NEW  PICTURE 

2)  Output  bundle  reps 

3)  Output  structures 

4)  end  frame 

That  is  XYX  explicitly  creates  a  frame  in  the  archive! 

Options 

Follows  are  a  list  of  options  to  rationalize  the  situation.  There  are  extremes 
and  the  expectation  is  some  more  moderate  solution  is  feasible 

a)  Drop  PHIGS  part  2  and  oart  3.  use  CGM  addenda  2 

b)  Drop  the  PHIGS  sections  of  CGM  Addenda  2.  Add  a  character  and  binary 
encodings  to  PHIGS  Archiver 

c)  Upgrade  CGM  Addenda  2  to  be  a  suoerset  of  CGM.  CGM  Addenda  t ,  CGM  Addenda  2 
(GKS-30  support)  and  PHIGS  part  2  and  part  3. 

d)  Remove  the  PHIGS  workstation  category  MO  and  Ml. 

I  do  not  believe  the  computer  graphics  community  is  served  by  several  file 
formats  which  are  almost  compatible. 
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Proposed  SC24/WG3  CGM  Position  on  Addendum  3 


The  CGEM  Rapporteur  Group  within  SC24/WG3  has  reviewed  the  proposed  NWI 
for  CGM  Addendum  3.  The  group  recogni2es  that  the  material  contained  therein  is 
ctirrently  appearing  in  various  defacto  standards  and  is  clearly  related  to  the  graphics 
standards  activity  of  SC24.  WG3  recommends  that  SC24  undertake  work  on  the  new 
•graphics  capabilities  encompassed  by  the  scope  of  Addendum  3*  It  is  recognized  that 
the  new  functionality  is  of  interest  not  only  to  metafiles,  but  to  API  and  other  areas 
as  well.  WG3  therefore  recommends  that  the  group  studying  this  new  functionality  be 
comprised  of  experts  from  all  areas  of  SC24  -  CGM,  CGI,  API  standards,  Reference 
Model,  Registration,  .... 
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APPENDIX  7 

ADDENDUM  3  DRAFT  FROM  FAIRFAX  MEETING 
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AHSI  X3H3 


Information  Processing  Systems  — 


Computer  Graphics  — 


Metafile  for  the  Storage  and  Transfer 
of  Picture  Description  Information 


Scope  Of  Specification 


Addendum  3 


Draft  Document  L-1 


June  21.  1938 
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Purpoaa 


The  purpose  of  this  addendum  is  to  extend  the  CGM  to  effectively  fulfill 
the  picture  transfer  requirements  of; 

1)  Engineering  drawing  and  technical  illustration 

2)  Graphics  arts  quality  pictures,  including  geometric  graphics,  raster 
images,  and  text 

3)  Technical  publishing 

An  additional  intent  is  to  keep  pace  with  the  graphics  requirements  of 
office  systems,  especially  ODA  requirements. 


Scope 

This  addendum  comprises  a  sec  of  elements  which  will  extend  the 
capabilities  of  CGM  as  needed  to  meet  additional  user  requirements  in 
engineering  drawing,  graphics  arts,  and  technical  publishing.  The  sec  of 
elements  should  include  all  elements  necessary  to  meet  chose  requirements. 
It  should  be  the  minimal  sec  sufficient  to  meet  chose  requirements 
effectively. 

t 

The  following  preliminary  list  of  capabilities  is  identified  as  necessary 
CO  meet  these  requirements. 

1)  Advanced  2D  graphics,  to  include: 

-  Bezier  curves 

-  Rational  3>splines 

-  Parametric  spline  curves 

-  Line  actribates  of  cap,  miter,  and  join 

-  Composite  line  primitive 

-  User-defined  line  types 

-  User-defined  hatch  styles 

-  Arbitrary  text  path 

-  Contes,  and  conic  arcs 

2)  Text  and  font  model  of  ISO  95<*1,  Information  Processing  —  Font  and 
Character  Information  Interchange. 

3)  Picture  composition  and  control,  to  include: 

.-  Arbitrary  clipping  boundary  'general  closed  curve! 

-  Shielding 

-  Alignment 

-< )  Additional  color  models  beyond  RGB 

-  CIE 

-  CMY3 

-  .Named  colors 

3}  Additional  raster  graphics  (scanned  image)  caoabiiities 

0/  Symbols;  external  reference  to  standard'  libraries  of  named  symbols 

The  scope  of  this  addendum  assumes  that  the  capabilities  of  TCM  addendum  1 
and  addendum  2  are  available. 
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Justification 


CCM  user  have  found  that  in  some  application  areas  the  present  standard 
provides  a  general  framework  that  is  suitable  but  lacks  some  functionality 
required  by  these  applications.  These  areas  include  engineering  drawing, 
the  preperation  of  graphic  arts  quality  presentation  materials,  and 
technical  publishing. 

A  recent  workshop  sponsored  jointly  by  the  MBS  and  Eurographics,  entitled 
'The  CCM  in  the  Real  World",  examined  this  issue  and  concluded  that  the 
CCM  lacked  capabilities  to  effectively  meet  some  advanced  user  needs.  As 
an  example,  for  engineering  drawlngsm  it  is  difficult  if  not  impossible  to 
effectively  represent  some  higher-level  constructs,  e.  g.  splines  and 
curves.  Though  such  constructs  can  be  simulated  with  simpler  primitives 
ain  the  CCM  at  present,  it  is  Immposlblr  to  maintain  accuracy  and  visual 
continuity  and  still  retain  device  independence. 

In  all  cases,  there  is  a  requirement  to  expand  CCM  text  to  Include  font 
definition  capabilities  that  are  consistent  with  the  ISO  DP95i*l  font 
standard.  The  font  definition  as  it  exists  in  ISO  3632  (CCM)  is  too 
general  for  practical  use.  Even  though  several  fonts  are  identified  in 
the  TOP  V3.  0  CCM  appl icat ion , Prof  lie ,  these  fonts  are  not  adequate  for 
publishing  and  graphics  arts  applications. 

Many  publishing  and  graphic  arts  systems  use  color  models  other  than  RC3 . 
For  efficiency  and  ease  of  implementation  in  these  areas,  for  example, 
additional  color  models  are  needed.  It  also  became  apparent  at  the 
workshop  that  the  Cell  Array  primitive  in  the  CCM  is  not  adequate  for  most 
applications  that  use  raster  graphics.  Thus,  this  addendum  will  also 
provide  additional  raster  graphics  capabilities. 
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Page  6 

Subclause  3:  Add  or  change  che  follav ing  entries: 

colour  model:  A  spec  If Icac Lon  of  a  3D  colour  coordinate  system  and  a  3D 
subspace  In  the  coordinate  system  within  which  each  dlsplayable  colour  Is 
represented  by  a  point.  Some  colour  models  Include  a  fourth,  redundant, 
dimension  to  allow  the  Independent  representation  of  black.  For  the  purpose 
of  ISO  3632  colour  model  refers  to  one  of  R.C3 ,  CIE  L*u«V'»,  or  CYMK. 

colour  selection  mode:  Indicator  as  to  whether  colour  selection  Is  to  be 
direct  (by  specifying  a  colour  value)  or  Indexed  (by  specifying  an  Index  Into 
a  table  of  colour  values).  See  COLOUR.  VALUE. 

colour  representation  method:  Indicator  as  to  which  of  three  colour  models 
(RGB,  CIE  L»u*viir,  CYMK)  or  spot  colour  Is  being  used  to  represent  colour 
values.  See  COLOUR  VALUE.  SPOT  COLOUR. 

colour  value:  The  character  string  (for  spot  colour)  or  values  of  the  point 
components  (for  colour  model)  describing  a  colour. 

RGB:  An  additive  colour  model,  well  matched  to  colour  display  monitors, 

whose  values  are  defined  by  the  normalized  weights  of  Red,  Green,  and  Blue 
components. 

CIE  L*u*v«:  A  colour  model  defining  an  absolute  colour  space  based  on  colour 
matching  experiments  whose  components  are  L»  (Lightness)  and  uw,  v» 
(Chromaticness). 

CTMK:  A  subtractive  colour  model,  common  In  the  printing  Industry,  which  has 
cyan,  magenta,  yellow,  and  black  components. 

spot  colour:  An  exactly  defined  colour  with  a  registered  name. 
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Page  10 


Subclause  4.  J;  Add  ehe  following  to  tre  list  of  elements  given  in 
the  first  paragraph  of  this  clause: 

COLOUR  REPRESENTATION  METHOD 

Page  1 0 

Subclause  4.3.  2.1:  dd  the  following  eleauncs  to  the  list. 

CONIC  ARC  COMIC  ARC  TRANSFORMATION  MATRIX 

PARAMETRIC  SPLINE  CURVE  RATIONAL  8-SPLINE  CURVE 
PEL  ARRAY  CLIP  RECTANGLE  RATIONAL  B-SPLINE  CURVE  CLOSED 
COMPRESSED  PEL  ARRAY  COMPRESSED  PEL  ARRAY  TILED 

PEL  ARRAY  REFERENCE  POINT 

Page  1 0 

Subclause  4.  3.  2.  1:  Add  the  following  to  the  list  of  elements  given 
in  the  second  paragraph  of  this  clause: 

COLOUR  REPRESENTATION  METHOD 


Page  1 2 


Subclause  4.  4.  2,  first  line: 
Changa  "dtrecc  (RGB)  colour' 

Into  "direct  colour" 


Page  14 


Subclause  d,  second  paragraph,  first  line: 

Change  "RGB" 

Into  "a  direct  colour" 


Page  x« 


Subclause  4.  5.  2:  add  the  fallowing  to  the  end  of  the  subclause : 

The  PEL  ARRAY  CLIP  RECTANGLE  Is  not  affected  by  the  setting  of  the  CLIP 
INDICATOR  eieraenc.  Pei  array  clipping  Is  assumed  to  be  always  on  The 
default  PEL  ARRAY  CLIP  RECTANGLE  Is  Listed  In  clause  6. 


Page  15 


Subclause  add  the  following  to  rhe  iLsc-. 

CONIC  ARC 

PARAMETRIC  SPLINE  CURVE 
RATIONAL  3-3PLINE  CURVE 
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rational  b-spline  curve  closed 

COMPRESSED  PEL  ARRAY 
COMPRESSED  PEL  ARRAY  TILED 


Fsge  15 

Subclause  ‘*.6:  add  ehe  falloving  co  "The  line  elements  are;  list 
CONIC  ARC 

PARAMETRIC  SPLINE  CURVE 
RATIONAL  B-SPLINE  CURVE 


Page  16 

Subclause  ‘*.6:  add  the  fallowing  to  "The  filled-acea  elements  are 
list: 

RATIONAL  B-SPLINE  CURVE  CLOSED 


Page  16 

Subclause  ^.6:  change  "The  cell  array  element  is:"  to  "The  cell 
srray  elements  are:  and  add  the  following  to  the  list. 

COMPRESSED  PEL  ARRAY 
COMPRESSED  PEL  ARRAY  TILED 


Page  16 

Subclause  6.  1.  1:  change  subclause  to  read  the  following'. 

•a.  6.  1.  1  Sescri ption.  There  are  cvo  general  line  elements  -  POLYL-ME  and 
DISJOINT  POLYLINE  -  four  line  elements  relating  to  circles,  ellipses  and 
conic  arcs,  and  two  elements  that  relate  co  spline  curves. 


Page  16 


Subclause  ‘^.6.1.  1:  change  the  end  of  the  subclause: 

CONIC  ARC  generates  a  parabolic,  hyperbolic  or  elliptical 

arc:  the  parameterization  of  the  arc(s)  Is 
described  in  5.  6.  X. 


/.XX  SPLINE  CURVE 


generates  a  single  snllne  curve;  two  seoarate 
carameter Izat Ions  of  the  spline  curve  are 
possible;  these  are  described  in  3.  h,  x  and 
5.  a.  X*  i 
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Page  16 

Subclause  4.  6.  1.  J:  change  the  last  sentence  of  the  subclause  to 
read: 

"The  ARC  and  SPLINE  primitives... 

Page  17 

Subclause  4.  6. 4. 1:  change  the  second  sentence  of  the  subclause  to 
read: 

"In  addition  there  are  seven  elements  that..."' 


Page  13 


Subclause  4.  6.  4.  1;  sdd  the  following  to  the  end  of  the  subclause: 

Rational  3-spline  curve  closed  generates  a  closed  3-spllne  curve: 

the  set  of  styles  Is  the  same  as 
for  POLYGON. 


Page  13 

Subclause  4.6.^.J  2nd  paragraph:  change  the  sentence  to  read: 

"The  circular,  elliptical  and  B-spllne  fill  primitives...” 

Page  13 

Subclause  4.^.3:  add  the  following  to  the  list: 

COMPRESSED  PEL  ARRAY  XXX  represents  a  rectangular  "olnary  L.Tiage 

compressed  according  to  the  CCITT  T4  or 
T6  facsimile  recommendations:  two 
parameterlzat Ions  are  possible,  one 
corresponding  to  the  normal  facslmlia- 
slze  image,  and  a  tiled  format  for  Large 
Images;  the  elements  are  described  in 
5.  6.  X  and  5.  6.  X.l. 


Page  13 


Subclause  6.  5:  add  the  following  at  the  end  of  the  subclause: 

-.9.0,.  Chaaing.  Clipping  of  the  pel  array  elements  Is  accomplished  jsinz 
^he  PEL  .-vRRrtf  CLIP  XECTANCLE.  Since  the  pel  array  clipping  mode  is  ai-avs 
assumed  to  be  on  ,  all  pel  array  elements  to  be  displayed  can  be  considered 
clioped.  The  default  pel  array  clip  rectangle  is  listed  In  Clause  b.  The 
PEL  ARRAf  CLIP  RECTANGLE  element  affects  the  pel  array  element  teat 
Immediately  follows  it  in  the  metafile,  or  if  no  pel  array  element 
immediately  follows,  it  affects  the  last  pel  array  previouslv  :i:'."'.ed.  In 
this  way.  multiple  clipped  pel  arrays  can  be  created  by  impilc  •  . 
referencing  just  one  occurence  of  a  pel  array  element. 
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U.6.5.2  Positioning.  The  position  of  a  clipped  pel  array  element  Is  defined 
by  the  PEL  ARRAY  REFERENCE  POINT  element.  The  reference  point  element 
affects  the  position  of  the  clipped  pel  array  that  Immediately  follows  It  In 
the  metafile.  If  a  clipped  pel  array  appears  In  the  metafile  without  a 
reference  point  Immediately  before  it,  the  array  is  positioned  at  the  last 
reference  point  previously  defined.  The  effect  on  whatever  might  already  be 
positioned  at  a  given  reference  point  Is  Implementation-dependent.  If  a 
reference  point  appears  with  no  pel  array  Immediately  following  It.  a 
duplicate  of  the  last  pel  array  previously  defined  Is  postloned  and  displayed 
at  the  reference  point. 

i.6.5.2  Tiling.  For  further  work,  will  be  based  on  the  Tiled  Raster 
Interchange  Format  specification  (TRIF  2.0).  The  state  of  this  specification 
within  CALS  and  8613  part  7  Is  too  unstable  to  begin  work  yet. 


Page  19 

Subclausa  <>.  6.  7 :  add  the  following  after  the  subclause: 

U.6-S  Conic  Arc  Element 

*w*N0TE  -  I  have  come  to  the  conclusion  that  the  ICES  specification  upon 
which  this  and  the  transformation  element  are  based  are  totally  unsulted  tor 
use  In  the  CCM.  This  parameterization  assumes  that  the  arc  Is  defined  In 
soma  nebulous  definition  space  that  is  then  transformed  to  model  space. 

Since  the  transformation  matrix  Is  only  3X3.  ICES  provides  a  mechanism  to 
concatenate  matrices  to  eventually  arrive  at  the  desired  orientation  In  model 
space.  The  CCM  has  no  such  mechanism.  In  addition,  the  entire  specification 
assumes  3-D  space,  and  changing  that  to  2-D  Is  not  as  simple  as  merely  zero¬ 
ing  out  the  2  term.  I  would  like  to  withdraw  the  arcs  and  splines  from  this 
specification,  and  spend  some  more  time  Investigating  ocher  possible 
algorithms. 

i.6.3.1  Ceometric  Concepts.  The  conic  arc  Is  defined  by  the  start  point,  end 
point  and  the  six  parameters  A-r.  To  determine  the  form  of  the  tonic  arc. 
the  quantities  Q1 .  Q2  and  Q3  are  defined  as  follows: 

:  A  B/2  D/2  : 

Q1  ■  determinant  of  !  3/2  C  E/2  ■ 

:  D  /  2  E .  2  F 

02  -  determinant  of  '  A  3.2! 

:  3-2  C  : 

Q3  ■  A  ♦  C 

1:  Q2>0  and  (Ql»03)<0.  then  tne  arc  Is  elllctlcal; 
if  02<0  and  01/>0.  then  t.he  arc  Is  hyperbolic: 

If  02»0  and  QloO,  then  the  arc  Is  parabolic. 

In  the  case  where  the  conic  arc  ts  elliptical,  to  distinguish  the  arc  ■. n 
question  from  its  comoii.ment.  the  direction  of  the  arc  with  rescect  to  70C 
space  must  be  from  start  point  to  end  ooint  l.n  a  counterc  loc.<wise  c^rection 

In  the  case  where  the  conic  arc  is  oarabolic  or  hyperbolic,  the 

parameter  izat  ion  defines  a  unique  portion  of  the  parabola  or  a  .n-.cue  rortLC". 

of  a  branch  of  the  hyperbola,  thus  the  direction  is  irrelevant. 
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i.6.3.2  Paraaeeerization.  A  conic  arc  is  defined  by  the  end  points  and  the 
six  parameters.  The  conic  arc  itself  is  defined  by  the  six  parameters  in  the 
following  equation: 

A(X«*2)  .  BXY  .  C(Y-«2)  .  DX  .  EY  •  F  -  0 

This  parameterization  assumes  that  VOC  space  is  <*  quadrant  cartesian 
coord inant  space.  The  CONIC  ARC  TRANSFORMATION  MATRIX  element  is  then  used 
to  properly  position  the  arc  in  the  COM  one  quadrant  7DC  picture  space. 


4.6*9  Spline  Curve  Elements 

^.6.9.1  Pacaameric  Spllna  Curve.  The  parametric  spline  curve  is  a  sequence 
of  parametric  polynomial  segments.  The  definition  of  this  class  of  curves 
generalized  to  allow  for  the  representation  of  many  different  parametric 
spline  curves  using  only  one  element.  The  following  curve  types  have  been 
assigned: 

1:  linear 
2:  quadratic 
3:  cubic 

4:  Wllson-Fowler 
5:  modified  Wllson-Fowler 
6:  3  spline 

6.  9.  1.1  Pacamececlzaeian.  The  degree  of  continuity  parameter  Indicates  the 
smoothness,  or  continuity  of  the  curve  with  respect  to  arc  length.  The  curve 
can  cither  be  continuous  at  all  break  points,  continuous  and  have  slope 
continuity  at  all  break  points,  or  be  continuous  and  have  both  slope  and 
curvature  continuity  at  all  break  points. 

The  number  of  segments  parameter  is  the  number  of  polynomial  segments  to  be 
used  to  define  the  curve.  Each  X.Y  polynomial  segment  Is  evaluated  using  the 
eight  polynomial  coefficients  associated  with  that  segment 
( AX , 3X ,CX, DX, AY , 3Y , CY , OY) .  Each  segment  Is  delimited  by  Its  respective 

breakpoint. 

4.6.  1.2  Ceoraeeric  Concepts.  The  following  cubic  polynomial  equations  -ILL 

return  the  coordinates  of  the  points  of  the  l-th  segment  of  the  curve.  Note 

that  the  coefficients  3,  or  G  and  0  vill  be  zero  If  the  coiynoralals  are  of 

degrees  2  or  1 ,  respect  iveiy: 

X(u)  -  AX(l)  -  3X(l)(s)  -  CX(l)(s  — 2)  -  DX(l)f3.r,j) 

Y(u)  -  AYCl)  -  3Y(i)(s)  ♦  CY(l)(s--2)  -  3Y(l)(s»»3) 

•Jhere  T(l)  <»  u  <-  T(l-l),l«l . N  and  s  ■  u  -  T(L}. 

The  terminate  point  and  derivatives  are  derived  without  computing  the 
polynomials  by  evaluating  the  Nth  oolynomiais  and  derivatives  at  j  .  T'N  . 

L).  These  data,  divided  by  tne  aopropriate  factorial  ; 1.  e.  the  secona 

derivative  divided  by  2!.  the  third  by  3!),  are  used  as  the  N-L  or  termlna-a 

point  values. 
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it.  6.  9.  2  Raeianal  B-Spline  Curve.  The  paramatrlc  equation  governing  the 
definition  of  the  rational  B-spiine  curve  Is  shown  In  the  following 
expression: 

W(0)»P(0)*b0(t)  W(l)*P(l)*bl(t)  W(K)*P(K).*bK(t) 

W(0)*b0(t)  W(l)«bl(t)  W(K)-bK(t) 

where  w(l)  are  the  weights,  P(l)  are  the  control  points  and  bl(c)  are  the 
basis  functions.  The  basis  functions  are  all  non-negative  piecewise 
polynomials  determined  by  the  degree  and  the  knot  sequence.  The  knot 
sequence  Is  a  non-decreasing  list  of  real  numbers  T( -M) , .  .  .  T( 0 ) , .  .  .  T( K* 1 ). 
Each  basis  function  Is  supported  for  the  knot  sequence  Interval  CT(l- 
M),T( 1*1)1,  where  M  Is  the  dgree  of  the  basis  function.  Between  any  two 
adjacent  knot  values,  the  corresponding  basis  function  can  be  expressed  as  a 
single  polynomial. 

The  curve  Itself  Is  parameterized  where: 

start_param  <■  t  <-  end_param, 

T(0)  <■  starc_param  <  end_param  <■  T(M) 

Thus  for  any  parameter  value  t  between  T(0)  and  T(K*1),  the  sum  of  the  basis 
functions  satisfies  the  following  Identity; 

b0(t)  *  bl(t)  *  _  *  bK(t)  -  1. 

If  all  of  the  weights  In  the  weight  list  are  not  equal,  then  the  equation 
type  Is  rational.  Otherwise,  If  all  of  the  weights  are  equal,  then  all  of 
the  weights  cancel,  the  denominators  sum  to  one  and  the  equation  type  Is 
polynomial. 


4 . 1C . Z  Compound  Line 

The  compound  line  elements  consist  of  the  two  elements.  3ECIM  COMPOUND  LIME 
and  END  COMPOUND  LINE.  These  elements  permit  the  definition  of  a  Line  that 
consists  of  a  number  of  distinct  elements,  such  as  straight  lines  and  arcs, 
which  Is  created  as  If  It  were  a  single  line  element.  Thus,  for  example, 
line  style  would  apply  without  change  or  Interruption  past  a  straight  Line 
segment  onto  a  following  arc  segment.  Likewise,  the  ends  of  the  /arlous 
component  elements  of  the  compound  line  are  not  treated  as  line  end. caps  but 
rather  as  line  joints. 


4.Z.Z  Compound  Text  Path 

The  comoound  text  path  elements  consist  of  the  two  elements,  3ECTM  COMPOUND 
TE.XT  ?.4TH  and  END  COMPOUND  TEXT  PATH.  I:  is  functionally  identical  to 
Comoound  Line,  except  that  It  is  used  as  a  base  Line  for  text  placement, 
ratner  tnan  arawn  by  an  Interpreter. 

The  Compound  Text  Path  permits  arbitrary,  complex  placement  of  text.  Each 
:ont  symbol  Is  placed  with  its  reference  point  and  alignment  according  to  ,t 
tangent  to  the  Compound  Text  Path.  This  Implicit  '•angent  is  the  logical  base 
line  for  each  character  cell.  If  a  symbol  s  reference  point  aligns  -tth  the 
junction  of  two  line  elements  of  the  Compound  Text  Path,  the  logical  base 
line  Is  the  line  perpend Icular  to  the  perpendicular  bisector  of  the  tangents 
of  both  elements,  passing  through  the  reference  point.  Positioning  of 
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subsauent  symbols  Ls  basad  upon  the  distance  between  symbols  assuming  a 
straight  base  line,  but  wrapped  along  the  generalized  curve  of  the  Compound 
Text  Path.  If  there  is  more  text  than  path,  the  path  for  the  excess  text  Is 
the  straight  line  described  by  the  tangent  to  the  last  element  of  the 
Compound  Text  Path. 


4.Z.Z  Picture  Composition 

The  picture  composition  elements  consist  of  BEGIN  CLIP  REGION,  END  CLIP 
REGION,  BEGIN  SHIELD  REGION,  END  SHIELD  REGION,  CLIP  INDICATOR,  and  SHIELD 
INDICATOR. 

The  concepts  of  clip  and  shield  regions  are  complementary.  The  clipping 
process  discards  everything  that  Is  visually  outside  the  clip  region  whereas 
the  shielding  process  discards  everything  that  Is  Inside  the  shield  region. 
Whether  clipping  and  shielding  are  In  effect  Is  determined  by  the  respective 
settings  of  the  CLIP  INDICATOR  and  SHIELD  INDICATOR  (each  is  either  ON  or 
OFF). 

Due  to  being  able  to  define  what  amounts  to  closed  figures  for  these  regions, 
the  clip  region  and  shield  regions  can  each  provide  a  clipping  and  a 
shielding  capability  at  the  same  time.  For  example,  a  polygon  with  a  hole' 
has  an  outer  boundary  and  an  Inner  boundary.  The  'filled  area"  of  such  a 
clipping  region  would  be  preserved  with  the  area  outside  the  "filled  area' 
(Including  the  contents  of  the  hole")  being  removed  from  t.Te  picture.  The 
shielding  region  has  a  complementary  interpretation:  the  "filled  area"  Itself 
Is  removed  from  the  picture. 

Note  that  the  shielding  effect  of  a  clip  region  "hole"  Is  Independent  of  the 
SHIELD  INDICATOR  and  likewise,  the  clipping  effect  of  a  shield  region  "hole" 
Is  Independent  of  the  CLIP  INDICATOR. 


?ag9  27 


Subclause  *>.  replace  the  current  text  body  vich  The  fallauir:g; 

The  COM  must  be  able  to  represent  colours  In  a  manner  suitable  to  a  broad 
spectrum  of  graphical  devices  and  systems.  Towards  this  goal,  the  CCM  uses 
three  colour  models  (RGB,  CIE  L»u<rv*,  CYMK.)  and  spot  colour.  The  -Metafile 
Descriptor  element,  COLOUR  REPRESENTATION  METHOD,  allows  metafile  generators 
to  specify  which  one  Is  being  employed. 

The  .^C3  additive  colour  model  uses  a  3-tupie  of  values  providing  the 
normalized  weight  of  the  red  (R).  green  (G) .  and  blue  (3)  components  of  the 
desired  colour.  This  model  Is  used  In  colour  monitors,  film  writers,  and 
Input  scanners.  The  source  and  destination  graphical  devices  must  be 
correctly'  calibrated  In  order  for  a  point  in  this  model  to  be  perceived  as 
the  same  colour  on  both  devices. 

The  CIE  ui.u-rv*  uniform  colour  model  uses  a  3-cuple  of  values  providing  the 
normalized  luminance  ;l«),  red-green  chromaticness  ( uv )  .  and  blue-yellow 
chromaticness  (vv»)  components  of  the  desired  colour.  The  advantages  of  the 
model  over  the  others  are  (1)  It  separates  chromaticness  from  luminance 
(allowing  for  easy  monochrome  display).  (2)  it  is  a  uniform  space  tor  small 
colour  differences  (the  Euclidean  distance  between  two  points  in  this 
model  Is  more  or  less  proportional  to  their  perceived  difference',  and  (3)  it 
IS  an  absolute  colour  model  based  colour  matching  experiments  (thus  being 
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device  Independent  and  not  requiring  colour  correction). 

The  CYMK  subtractive  colour  model  uses  a  4-tuple  of  values  providing  the 
normalized  weights  of  the  cyan  (C),  yellow  (Y),  magenta  (M),  and  black  (K) 
components  of  the  desired  colour.  This  model  Is  used  by  printers  and 
Graphics  Arts  drum  scanners.  In  theory,  cyan,  magenta,  and  yellow  are  meant 
to  correspond  to  the  red,  green,  and  blue  of  the  R.GB  model.  In  practice, 
actual  Inks  used  for  colour  printing  only  approximate  this  criterion. 

Slack  ink  is  added  to  attain  a  greater  dynamic  range  than  Is  possible  with 
three  colours  alone.  In  particular.  It  allows  the  attainment  of  a  much 
richer  black  than  would  be  possible  using  only  the  first  three  Inks. 

Spot  colour  uses  a  character  string  representing  a  registered  or  private 
colour  name  (similar  In  format  to  named  fonts).  Use  of  the  former  Is 
recommended  for  metafile  transportability,  because  registration  ensures 
unique  naming  of  colours.  Spot  colours  are  registered  in  the  ISO 
International  Register  of  Graphical  Items,  which  is  maintained  by  the 
Registration  Authority.  when  a  spot  colour  has  been  approved  by  the  ISO 
Working  Group  on  Computer  Graphics,  the  colour  name  will  be  assigned  by  the 
Registration  Authority.  Each  registered  colour  will  be  specified  in  terms  of 
its  CIE  L«uwv*  coordinates. 

The  CGM  provides  two  mechanisms  for  colour  selection:  direct’  and 

Indexed'.  In  direct'  colour  selection,  the  colour  Is  specified  by 
providing  values  for  Its  normalized  components  (colour  model)  or  by  providing 
the  character  string  defining  Its  name  (spot  colour).  (The  term  direct 
colour  value'  will  refer  to  any  direct  colour  specifier,  and  the  term  direct 
colour  model  value'  will  refer  only  to  a  direct  colour  specifier  of  a  colour 
modal  (as  opposed  to  spot  colour)).  In  'indexed'  colour  selection,  the 
colour  is  specified  by  an  index  into  a  cable  of  direct  colour  values. 
Selection  of  one  of  these  “mechanisms  may  be  dona  by  an  element  in  each 
Picture  Descriptor. 

.•or  indexed'  colour  selection,  the  COLOUR  T.ABLS  attribute  element  is 
provided  for  changing  the  contents  of  t.ne  colour  table.  This  element  may 
appear  throughout  the  picture  body.  However,  the  effect  of  changes  in  the 
colour  table  on  any  e.xlsclng  graphical  primitive  elements  that  use  t.-.e 
affected  indices  is  not  addressed  in  this  Standard. 

Direct  colour  model  values  are  either  a  3-tuple  or  ^-tuple  of  values 
providing  the  normalized  weight  of  the  desired  colour  comoonents.  In  the 
aostract,  eacn  component  is  normalized  to  tne  continuous  range  of  real 
numbers  CO. II.  In  a  metafile,  direct  colour  model  value  components  are 
integers,  and  the  Metafile  Descriptor  element.  COLOUR  ’/AL'JE  EXTENT,  allows 
metafile  generators  to  specify  the  minimum  and  maximum  metafile  direct 
colour  model  values  for  normalization. 
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Sub-clausa  5.  1:  Table  of  data  type  abbreviations: 


Replace 

CD  Colour  Direct  Three-tuple  of  non-negative  real  values  for 

red,  green,  blue  colour  Intensities. 

with 


MD  Model  Direct  Three-tuple  or  four-tuple  of  non-negative 

real  values  for  colour  definition  within 
one  of  the  three  supported  colour  models. 

CO  Colour  Direct  String  or  Model  Direct  (as  determined  by 

COLOUR  .REPRESENTATION  METHOD). 


Pages  ^7-43 

Sub-clause  3.3.7:  Replace  the  description  as  follows: 

The  precision  for  operands  of  data  type  model  direct  (MO)  Is  specified  for 
subsequent  data  of  type  MD.  The  precision  Is  defined  as  the  field  width 
measured  In  units  applicable  to  the  specific  encoding. 

Although  the  form  of  the  parameter  Is  encoding  dependent,  the  parameter  Is  a 
single  specification  that  applies  to  each  or  all  of  the  three  or  four 
components  of  parameters  of  type  CM..  The  precisions  of  the  Individual 
components  are  not  Independently  and  differently  specifiable  by  this  element. 


Pages  43-49 

Sub-clause  5.  3.  10:  Replace  the  description  as  follows: 

The  parameters  represent  an  extent  which  bounds  the  direct  colour  model 
values  that  will  be  encountered  In  the  metafile.  It  need  not  represent  the 
exact  extent  of  colour  model  values  contained  In  the  metafile. 
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Subclause  5.  3:  Add  the  following  fietafile  Descri pter  Elements: 
3.3.x  COLOUR  REPRESENTATION  METHOD 
Parameters: 

colour  representa  t  Ion  method  f  one  of:  .RC3  ,  CIE  L>.u,fV., , 

CVMK.  spot  colour)  (E) 

Description: 

Four  methods  of  colour  representation  are  supported:  by  one  of  three 
colour  models  (RGB,  CIE  LvrUwVv, ,  CYMK)  or  by  spot  colour  (names). 


Only  one  colour  representation  method  may  be  used  within  a  metafile. 
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Tha  method  may  be  defaulted  or  explicitly  set  with  the  COLOUR 
REPRESENTATION  METHOD  element.  All  occurrences  of  colour-setting 
elements  (AUXILIARY  COLOUR,  LINE  COLOUR,  MARKER  COLOUR,  FILL  COLOUR, 
EDGE  COLOUR,  TEXT  COLOUR)  as  well  as  the  colour  lists  of  CELL  ARRAY  and 
PATTERN  TABLE  shall  be  In  the  current  method.  If  used,  COLOUR 
REPRESENTATION  METHOD  shall  be  In  the  Metafile  Descriptor,  after  BEGIN 
METAFILE  and  before  BEGIN  METAFILE  BODY. 

References: 

k.  7.  7 


5.3.x  FONTMETRIC  DEFINITION 

Parameters: 

font  Index  (IX) 
character  Index  (C) 

left  bearing  (format  to  be  determined) 
right  bearing  (format  to  be  determined) 
character  height  (format  to  be  determined) 
offset  from  baseline  (format  to  be  determined) 

Description: 

The  fontmetrlc  Information  for  each  character  used  In  each  font 
specified  Is  defined  by  this  element.  If  this  element  Is  used,  then 
the  fontmetrlc  data  for  each  character  used  In  the  metafile  must  be 
specified.  Characters  not  used  by  the  metafile  may  also  be  specified, 
but  are  not  required. 

References: 


S.3.X  CHARACTER  KERNING  MODE 
Parameters: 

character  Icernlng  mode  (one  of:  none,  pair,  sectored)  (E) 


Description: 

Defines  the  kerning  style.  If  any,  for  the  metafile. 

References: 


3.3.x  CHARACTER  KERNING  TABLE 
Parameters : 

To  be  determined. 

Description: 

The  data  defined  by  this  element  will  be  dependant  upon  which,  if  an-/, 
kerning  styles  are  supported.  In  general,  however,  the  Information 
will  be  that  which  Is  required  to  kern  characters. 

References : 


I 
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5.3.x  FCS  TTPE 
Parana Cars: 

Font  coordinate  type  (one  of;  Integer,  real,  VDC)  (E) 

Description: 

The  single  parameter  Is  an  enumerated  value  that  declares  the  data 
type.  Integer  or  real,  of  the  font  coordinate  space.  Font  coordinate 
space  may  be  different  than  VDC  space  because  higher  precision  may  be 
necessary  to  accurately  define  the  fontmatrlc  data.  However,  If  the 
font  coordinate  type  Is  VDC,  then  the  font  coordinate  space  will  map  t 
VDC  space.  In  this  case,  no  additional  specification  for  font 
coordinates  (FCS  INTEGER  PRECISION,  FCS  REAI.  PRECISION,  or  FCS  EXTENT) 
need  be  specified. 

References: 


5.3.x  FCS  INTEGER  PRECISION 
Parameters: 

Encoding  dependant. 

Descript ion: 

The  Indicated  Integer  precision  for  fontmetrlc  data.  The  precision  is 
defined  as  the  field  width  measured  In  units  applicable  to  the  specif! 
encoding. 

References: 


5.3.x  FCS  REAL  PRECISION 
Parameters: 

Encoding  dependant. 

Descript  Ion: 

.The  indicated  real  precision  for  fontmetrlc  data.  The  precision  is 
defined  as  the  field  width  measured  in  ^nits  applicaole  to  t.ie  soar 
encoding. 

References: 


5.3.x  CAP  HEIGHT 

Parameters : 

To  oe  determined. 

Descript  Ion: 

To  be  determined. 

■References : 
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5.3.x  FCS  EXTENTS 

Paraaatars: 

first  corner  (P) 
second  corner  (P) 

Description: 

The  two  corners  define  a  rectangular  extent  In  font  coordinate  space 
that  demarcates  a  two-dimensional  Cartesian  coordinate  system.  Each 
character  definition  within  a  font  must  be  defined  completely  within 
this  coordinate  system. 

MOTE  ***  The  need  for  this  element  Is  specified  In  ISO  9541-5, 
clause  4.  The  Intent  of  this  element  Is  to  address  the  needs  outline 
by  ISO.  Additional  works  must  ba  dona* 

References : 


P3^e  55 

Sub-clause  5.^.2.  firsc  paragraph  of  descripeion; 

Change  "red,  green,  and  blue"  Into  “direct" 

Page  57 

Sub-clause  5.^-.  7,  firse  line  of  second  paragraph  of  description: 
Change  "RG3"  Into  "a  direct  colour  value" 


Page  60 


Subclause  5.5:  .Add  the  fallowing  Control  Sleaents: 

5.5.x  BEGIN  COMPOUND  LINE 
Paramatars : 
none 

Description: 

BEGIN  COMPOUND  LINE  delimits  the  beginning  of  a  definition  of  a  anti; 
that  will  have  consistent  line  attributes  and  will  be  treated  as  a 
single  "compound  primitive’.  The  elements  tnat  matte  up  the  compouna 
line  can  bo  any  combination  of  non-ciosed  Line  elements  such  as 
POL’fLINE,  CIRCULAR  ARC  3  POINT,  CIRCULAR  ARC  CE.NTRH.  ELLIPTICAL  ARC, 
<new  curve  elements). 

References : 


5.5.x  END  COMPOUND  LINE 
Parameters : 
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none 

Description: 

END  COMPOUND  LINE  dellalts  the  end  of  a  compound  line  definition. 

References: 


5.5.x  BEGIN  COMPOUND  TEXT  PATH 
Parameters: 
none 

Description: 

BEGIN  COMPOUND  TEXT  PATH  delimits  the  beginning  of  a  definition  of  a 
entity  chat  vlll  provide  the  path  In  which  a  text  string  will  be  drawn. 
The  elements  that  make  up  the  compound  text  path  can  be  any  combination 
of  non-closed  line  elements  such  as  POLYLINE,  DISJOINT  POLYLINE, 
CIRCULAR  ARC  3  POINT,  CIRCULAR  ARC  CENTRE,  ELLIPTICAL  ARC,  or  <new 
curve  elements). 

Once  defined,  the  compound  text  path  takes  the  place  of  the  text  path 
as  defined  by  the  TEXT  PATH  element  and  the  CHARACTER  ORIENTATION 
elements.  The  skew  of  the  characters  Is  still  relative  to  that 
specified  In  the  CHARACTER  ORIENTATION  element,  but  the  placement  of 
subsequent  characters  is  along  the  compound  text  path  Instead  of  In  a 
line  along  the  character  up  vector  or  character  base  vector. 

References: 


5.5.x  END  COMPOUND  TEXT  PATH 
Parameters: 
none 

Description: 

END  COMPOUND  TEXT  PATH  delimits  the  end  of  a  compound  text  path 
definition. 

References: 


5.5.x  BEGIN  CLIP  REGION 
Parameters: 
none 

Descript  Ion: 

BEGIN  CLIP  REGION  delimits  the  beginning  of  a  definition  of  a  entity 
that  will  provide  the  clipping  region.  When  CLIP  INDICATOR  is  on 
only  the  portions  of  graphics  elements  Inside  or  on  the  boundary  of  toe 
clipping  region  are  drawn.  The  elements  that  .make  up  the  clippi.ng 
region  can  be  any  combination  of  closed  or  non-closed  elements  such  as 
POLYLINE,  DISJOINT  POLYLINE.  POLYGON,  POLYGON  SET,  CIRC'JL.-iR  A.RC  3 
POINT.  CIRCULAR  .ARC  3  POINT  CLOSE.  CIRCULAR  ARC  CENTRE.  CIRCULAR  ARC 
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CENTRE  CLOSE,  ELLIPTICAL  ARC  CLOSE,  or  <new  curve  elements).  The 
entity  thus  defined  is  essentially  a  closed  figure  whose  boundary  is 
used  as  the  clipping  boundary. 

Once  defined,  the  clipping  region  takes  the  place  of  the  clipping 
region  defined  in  CLIP  RECTANGLE. 

References: 


S.5.X  END  CLIP  REGION 
Parameters: 
none 

Description: 

END  CLIP  REGION  delimits  the  end  of  a  clipping  region  definition. 
References: 


s.s.z  BEGIN  SHIELD  REGION 

Parameters: 

none 

Description: 

BEGIN  SHIELD  REGION  delimits  the  beginning  of  a  definition  of  a  entity 
that  will  provide  the  shielding  region.  When  SHIELD  INDICATOR  is  on 
only  the  portions  of  graphics  elements  outside  of  the  shielding  region 
are  drawn.  The  elements  that  make  up  the  shielding  region  can  be  any 
combination  of  closed  or  non-ciosed  elements  such  as  POLYLINE,  DISJOIN 
POLYLINE,  POLYGON.  POLYGON  SET,  CI.RCULAR  .^RC  J  POINT,  CIRCULAR  ARC  3 
POINT  CLOSE,  CIRCULAR  ARC  CENTRE.  CIRCULAR  ARC  CENTRE  CLOSE.  ELLIPTICA 
ARC  CLOSE,  or  <new  curve  elements).  The  entity  thus  defined  is 
essentially  a  closed  figure  whose  boundary  is  used  as  the  shielding 
boundary. 

References: 


5.S.X  END  SHIELD  REGION 
Parameters : 
none 

Descr ipt ion : 

END  SHIELD  REGION  delimits  the  end  of  a  shielding  region  definition 

References: 


« 
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S  •  5  •  X  SHI £1.1) INC  INDICATOR 

Parafflctars: 

shield  Indicator  (one  of;  off,  on)  (E) 

Oascrlptlon: 

When  SHIELD  INDICATOR  Is  off,  shielding  of  graphical  primitive 
elements  Is  not  required. 

When  SHIELD  INDICATOR  Is  'on' ,  only  those  portions  of  graphical 
primitive  elements  outside  of  the  shielding  region  are  dravn. 

References: 
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Sub-clause  5.  6.  9:  Add  the  following  at  the  end  of  the  third 
paragraph  of  the  description: 

Note  that  COLOUR  PRECISION  only  applies  to  direct  colour  model  values. 


Page  77 


Subclause  5.6:  Add  the  following  Graphical  Primitive  Elements: 


5.6.x  CONIC  ARC  #**PRELIMINART*** 

Parameters: 

start  point  (P) 
and  point  (p) 

A.3,C.D.E,.s-  (6R) 

Description: 

A  conic  arc  Is  drawn  which  Is  defined  as  follows: 

A  conic  arc  Is  defined  by  the  end  points  and  the  sl:t  parameters.  The 
conic  arc  Itself  La  defined  by  the  six  parameters  In  the  ioilowLng 
equation: 


A(X**2)  •  BXY  •  C(Yi»*2)  ♦  DX  •  EY  •  F  •  0 

In  order  for  the  conic  arc  to  be  processed  correctly  by  the  receiving 
system  given  the  above  renresentat Ion .  the  conic  arc  entity  must  be 
positioned  such  chat  each  of  Its  a:ccs  Is  parailei  to  either  -he  XT  nxls 
or  XT  axis.  The  arc  Is  then  positioned  correctly  In  7DC  soace  by  using 
tne  value  of  the  CONIC  ARC  TRANSFORMATION  MATRIX  element. 

To  determine  the  form  of  the  conic  arc.  tne  quantities  QI.  02  and  Q3  are 
defined  as  follows; 


Ql  •  determinant  of 


A.  B  /  2  D  /  2 
3/2  C  E/2 
0/2  E/2  F 
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C2  -  determinant  of  !  A  3/2  : 

13/2  C  ! 

Q3  ■  A  ♦  C 

If  Q2>0  and  (Q1»Q3)<0,  then  the  arc  Ls  an  ellipse. 

If  Q2<0  and  QloO,  then  the  arc  Is  a  hyperbola. 

If  Q2-0  and  QloO,  then  the  arc  Is  a  parabola. 

In  the  case  where  the  conic  arc  Is  elliptical,  to  distinguish  the  arc  in 

question  from  Its  compliment,  the  direction  of  the  arc  with  respect  to 
the  definition  space  must  be  from  start  point  to  end  point  in  a 
counterclocicwise  direction. 

In  the  case  where  the  conic  arc  Is  parabolic  or  hyperbolic,  the 
parameterlzat Ion  defines  a  unique  portion  of  the  parabola  or  a  unlaue 
portion  of  a  branch  of  the  hyperbola,  thus  the  direction  Is  irrelevant. 

The  direction  of  the  conic  arc  with  respect  to  7DC  space  Is  determined 
by  the  original  direction  of  the  arc  In  definition  space.  In  conjunction 
with  the  action  of  the  CONIC  .ARC  TRANSFORflATION  MATRIX  element. 

References: 

4  . 


5.6.x  CONIC  ARC  TRANSFORMATION  .MATRIX  •**?RELIMINART*** 

Parameters: 

matrix  elements 

If  the  VDC  type  Is  Integer', 

R11,R12,.R21,R22  (41) 

If  the  VDC  type  Is  real', 

Ril,.Rl2,R21..R22  (4R) 

coordinate  offset  (P) 


Description: 

This  element  Is  Intended  to  woric  la  conjunction  wi:h  the  CONIC  A.RC 
element  to  transform  the  conic  arc  from  definition  space  to  '/2C  space. 
The  Transformation  Matrix  entity  transforms  the  definition  space  point 
coordinates  by  means  of  a  matrix  multiplication  and  then  the  audition  of 
an  offset. 

The  notation  for  this  transformation  is  as  follows: 

.  Rll  R12  ;  ;  Xln  :  ♦  :  TL  :  -  :  .'Cout  ; 

:  .^21  K22  :  :  /in  :  ■  72  '  :  Tout  ; 

where  iRljl  Is  the  transformation  matrl.x.  (Xln, Tin)  is  the  coordinate  to 
be  transformed,  (T1,T2)  Is  the  offset,  and  (Xout,iout)  is  the  coordinate 
resulting  from  the  transformation.  3oth  the  input  and  output  coordinate 
systems  are  assumed  to  be  orthogonal,  cartesian  and  right-handed. 
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Rafaraneas: 

4. 


S-6-Z  PARAMETRIC  SPLINE  CURVE 

Paraaatars: 

curva_type  (IX) 

H-degree  of  continuity  (I) 

N-nufflbar  of  segmants  (I) 

T-break  point  List  for  polynomial  ((M*1)R) 

X  coordinate  polynomial  list  (N  sets  of  four) 

AX.SX.CX.DX  (N-4R) 

I  coordinate  polynomial  list  (N  sets  of  four) 

AV.BY.CY.OY  (N*4R) 

Oascrlptlon: 

The  parametric  curve  to  be  dravm  Is  defined  as  follows: 

The  parametric  spline  curve  Is  a  sequence  of  parametric  polynomial 
segments.  The  parameterization  shown  abova  Is  generalized  to  allow  for 
the  representation  of  many  different  parametric  spline  curves  using  this 
one  element.  The  curve_type  parameter  Indicates  the  type  of  parametric 
curve  as  It  was  represented  In  the  sending  system  before  being  converted 
to  this  generic  form.  The  following  curve  types  have  been  assigned: 

1:  linear 
2:  quadratic 
3:  cubic 

4:  Wtlson-Fowler 
5:  modified  Xllson-Fowler 
6:  3  spline 

Values  above  6  are  reserved  for  registration  and  future  standardization, 
and  negative  values  are  available  for  Implementation-dependent  use. 

The  degree  of  .ontlnulty  parameter.  H,  Indicates  the  smoothness,  or 
continuity  of  the  curve  with  respect  to  arc  length.  If  a»0.  the  curve 
is  continuous  at  all  break  points.  If  d-1.  the  curve  Is  continuous  and 
has  slope  continuity  at  all  break  points.  If  H-2,  the  curve  is 
continuous  and  has  both  slope  and  curvature  continuity  at  all  break 
points. 

The  number  of  segments  parameter.  N.  Is  the  number  of  polynomial 
segments  to  be  used  to  define  the  curve. 

ihe  parametric  spline  curve  Is  displayed  with  the  current  line 
attributes. 

**•  Additional  Info-  on  degeneracies  required  *** 

References: 

4. 
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5.6.x  RATIONAL  B-SPLINE  CURVE 
Paraoaters: 

X-upper  Index  of  sum  (I) 

«-degree  of  the  basis  function  (I) 

equat lon_t7pe  flag  (one  of:  rational,  polynomial)  (E) 
periodic  flag  (one  of:  non-perlodlc .  periodic)  (E) 

T-knot  sequence  list  ((K*M'»2)R) 

W-walght  list  ((K.l)R) 
control  point  list  ((K»1)P) 
start_param, end_paraffl  (2R) 

Description: 

A  rational  spline  curve  Is  drawn  which  Is  defined  as  follows: 

«««  Additional  info,  required.  *** 

Valid  values  of  the  upper  Index  and  degree  paramenters  are  non- 
negative  Integers. 

Valid  values  of  the  control  points  are  such  that  no  two  adjacent 
points  are  coincident. 

If  all  of  the  weights  In  the  weight  list  w  are  not  equal,  then  the 
equac lon_t ype  flag  Is  set  to  Rational,  otherwise  the  equat lon.type  flag 
Is  set  to  Polynomial. 

References: 

4. 


5. 6.x  COMPRESSES  PEL  ARRA7 
Parameters: 

T-encodlng  type  (one  of:T«,T6)  (E) 

?-pel  path  (one  of : 0 , 90 , 130 , 2T0 )  (  Z) 

L-llne  progression  (one  of: 90,270)  (E) 

3-pel  spacing  (R) 
spac lng_rat lo  (R) 

M-number  of  pels  per  line  (I) 

^{L-^umber  of  lines  (I) 
pel  array  (3S) 

Description: 

A  comoressed  pel  array  Image  is  defined  as  follows; 

The  encoding  type  parameter.  T,  specifies  the  CCITT  compression  foma: 
used  to  encode  the  image.  If  T  Is  specified  as  'T- '  .  the  image  Is 
encoded  according  the  one  or  two  dimensional  scheme  defined  in  CCITT 
Recommendation  u  (Group  3  facsimile).  If  T  Is  'T6‘.  the  image  is 
encoded  according  to  the  two  dimensional  scheme  defined  in  CCITT 
.Recommendation  T.  5  (Group  <*  facsimile). 

The  position  of  the  upper  left-hand  corner  of  the  clipped  oel  array  is 
defined  by  the  reference  point  (See  ?EL  ARRAY  CLIP  .RECTANGLE). 

The  pel  path  parameter,  P,  is  the  direction  of  progression  of  successive 
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pels  along  a  line  relative  to  the  VDC  X  axis.  This  parameter,  In 
conjunction  with  the  pel  spacing,  S,  and  the  number  of  pels  per  line,  V, 
Implicitly  define  the  line  position,  length  and  granularity  for  each 
line  In  the  decoded  pel  array.  The  spaclng_rat lo  Is  defined  as  the 
ratio  M/S.  where  "M"  Is  the  distance  In  Basic  Measurement  Units  ( BMUs  - 
1200  BMUs  per  Inch)  between  two  successive  lines  of  pels,  and  S'  is  the 
distance  In  BMUs  between  two  adjacent  pels  In  a  line. 

The  line  progression  parameter,  L.  Is  the  direction  of  progression  of 
successive  of  pel  lines  and  Is  expressed  as  a  direction  relative  to  P. 

L,  In  conjunction  with  the  spaclng_rat lo  and  the  number  of  lines,  ML, 
implicitly  defines  the  size  of  the  decoded  Image  In  the  direction  of  L. 
The  line  spacing  (LS)  of  the  lines  of  pels  can  be  determined  as  follows; 

LS  ■  spaclng_r3t lo  *  S 

The  pel  array  Itself  Is  stored  in  the  formats  defined  by  T.  encoded  as  a 
blt_stream. 

References: 

4. 


5.6.Z  PEL  ARRAY  TILED  ••«PR£LIMINART«*« 
Parameters: 

T-encodlng  type  (one  of : bitmap , T4 , T6 )  (E) 

P-pel  path  (one  of ; 0, 90, 180. 270)  (E) 

L-ilne  progression  (one  of: 90,270)  (E) 
S-pel  spacing  (R) 
spaclng«.ratlo  (R) 

MT-number  of  tiles  (I) 

M-number  of  pels  per  line  (I) 

NL-number  of  lines  (I) 

TO-tlle  dimensions  (21) 

pel  array  (3S) 


Oescrlpclon: 

A  tiled  pel  array  Image  is  defined  as  follows; 
•««  Additional  speclfeatlon  required* 
References; 


5.6.x  PEL  .ARRAY  CLIP  RECTANGLE 

Parameters : 

X1,T1.X2,T2  (<41) 

first  corner  (?) 
second  corner  (P) 

Description: 

The  element  defines  the  rectangular  area  of  pels  in  the  decoded  ret 
array  chat  Is  to  aopear  in  the  metafile  picture.  This  element  shoula 
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immediately  precede  the  COMPRESSED  PEL  ARRAY  element  to  which  it 
applies,  as  this  element  will  affect  all  subsequent  COMPRESSED  PEL  ARRAY 
elements  until  another  PEL  ARRAY  CLIP  RECTANGLE  is  explicitly  defined. 

The  four  integers  form  two  coordinate  pairs.  (Xl.Yl)  and  (X2,Y2) 
corresponding  to  the  first  and  last  pels  to  appear,  respectively,  wnere 
X1<*X2  and  Y1<«Y2.  For  example,  (6,2)  would  specify  the  seventh  pel  i.n 
line  3,  given  that  (0.0)  specifies  the  first  pel  on  the  first  line. 

The  two  corner  points  define  the  clipped  pel  array  to  be  positioned  in 
VDC  space.  The  first  pel  defined  by  (Xl.Yl)  above  is  to  be  positioned 
at  the  reference  point  of  the  COMPRESSED  PEL  ARRAY  element.  Only  those 
portions  of  the  decoded  pel  array  from  the  COMPRESSED  PEL  ARRAY  element 
inside  or  on  the  boundary  of  the  pel  array  clip  rectangle  are  to  be 
rendered. 

References: 

4. 


5.6.x  PEL  ARRAY  REFERENCE  POINT 
Parameters: 

ref erence_poinc  (P) 

Description: 

The  pel  array  reference  point  defines  the  upper  left-hand  corner  of  the 
pel  array  element  to  be  displayed.  If  the  pel  path  and  line  progression 
are  thought  of  as  vectors,  the  upper  left-hand  corner  is  defined  as 
point  of  origin  for  the  two  vectors. 

References: 

>4  , 


?3ge  97 


Subclause  5.7;  .Add  Che  folLaving  accribuce  aleaencs; 

5.7.x  LINE  TYPE  DEFINITION 
Parameters: 

line  type  I'XX) 

dasn  unit  selector  (one  of:  7DC ,  Tim.  native  device  units,  abstract)  Z' 

dasn  repeat  lengtn  (R) 

adaptive  flag  (one  of;  no,  yes)  '’E) 

list  of  dash  elements  (ni) 

Description: 

This  element  defines  a  linetype  and  associates  it  witn  an  index  for 
future  reference.  Parameter  linetype  is  the  index  of  Linetyce  being 
defined.  The  parameter  list  of  dash  elements  is  the  definition  to  be 
associated  with  the  index.  The  first  element  is  a  dash,  second  a  soace, 
etc.  —  the  defined  linetype  is  solid  for  II  units,  gap  for  IZ  units, 
solid  for  13  units,  etc.  M  must  be  positive,  and  each  dash  eiement  ,I 
non-negative.  N»1  means  a  solid  line:  I»0  interpreted  as  a  doc. 
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The  units  of  the  'dash  repeat  length’  are  specified  by  the  dash  unit 
selector’  parameter.  The  value  of  abstract’  indicates  that  the 
implementation  may  normalize  and  map  the  sura  of  the  dash  pattern  elements 
at  its  discretion.  The  dash  repeat  length’  defines  the  length  of  one 
complete  cycle  of  the  dash  pattern,  measured  in  the  units  of  dash  unit 
selector ’ . 

An  ’adaptive'  linetype  is  one  where  every  vertex  falls  on  an  inked 
portion  of  the  line.  This  is  accomplished  in  plotters  by  temporarily 
modifying  the  duty  cycle  for  each  line  segment  (ceiling  function)  such 
that  there  is  always  an  integral  number  of  repeats. (and  all  predefined 
linetypes  have  their  gaps.array  defined  such  that  they  begin  and  end  with 
inked  or  ’’pen  down”  portions). 

References: 


5.7.x  HATCH  STTLE  DEFINITION 

Parameters: 

hatch  index  (IX) 

style  indicator  (one  of;  parallel,  crosshatch)  (E) 

hatch  space  units  selector  (one  of:  '/DC,  mm,  device  units,  abstract)  .Z) 
angle  (2R) 

duty  cycle  length  (R) 

list  of  hatch  elements  (nl)  -  I>»0,  n>«2 
Description: 

This  element  defines  a  hatch  style  and  associates  it  with  an  index 
for  future  reference. 

The  ’hatch  index’  parameter  defines  the  index  of  hatch  style  being 
defined.  The  ’list  of  hatch  elements  is  an  array  that  defines 
alternating  line  width  and  gap  width  --  i.  e.  ,  the  width  of  a  natch  line 
followed  by  the  width  of  the  space  to  the  next  hatch  line.  The  center  oi 
the  first  hatch  line  is  matched  up  with  PATTERN  REPERE.NCE  PCI.NT.  if 
implemented.  0  interpreted  as  thinnest  line  width  available. 

The  hatch  space  units  selector’  soecifies  the  units  of  duty  ty-le 
length’.  It  also  controls  the  manner  of  transformation  of  tne  na  t  c n; : 
If  ’/DC.  then  the  hatching  transforms  with  segment  transform  ana 
anisotropic  transforms  (as  if  hatching  had  done  POL’f  LI.NES ) :  otherwise, 
tne  hatching  is  like  ’’wallpaper’  that  shows  through  the  poly gon-shaoea 
hole  --  everything  is  defined  in  device  units  and  hatching  performea  in 
device  space.  The  value  of  abstract’  indicates  that  the  implementation 
may  normalize  and  map  the  sum  of  the  list  of  hatcn  elements  at  its 
discretion.  The  duty  cycle  length’  is  me.isiircd  perpendicular  to  tne 
hatch  line.  The  sum  of  hatch  elements  in  the  hatch  element  list  is 
normalized  to  this  distance  before  presentation  of  the  hatch  on  t.ne  .•le-- 
surface. 

The  angle’  parameter  is  measured  in  the  units  specified  by  the  hatrn 
space  units  selector  .  It  consists  of  two  components,  dx  and  dy , 
defining  a  vector. 
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5.7.x  LINE  CAP 
Parameters: 

line  cap  Indicator  (one  of:  butt,  round,  projecting  square)  (E) 
Description: 

The  line  cap  style  is  defined  for  subsequent  line  elements.  The  line  cap 
style  determines  the  appearance  of  open  endpoints  (as  opposed  to  interior 
vertices)  of  line  elements.  The  defined  styles  are: 

butt  cap:  the  line  is  squared  off  at  the  endpoint,  there  is  no 
projection  beyond  the  endpoint. 

round  cap:  a  semicircular  arc  with  diameter  equal  to  the  line  vidth 
is  drawn  around  the  endpoint  and  filled  in.  The  drawn  line  thus 
projects  beyond  the  endpoint, 

projecting  square  cap:  the  line  is  squared  off  at  a  distance  equal  to 
half  the  line  width  beyond  the  endpoint. 

References: 


5.7.x  LINE  JOIN 
Parameters: 

line  join  Indicator  (one  of;  miter,  round,  bevel)  (E) 

Description: 

The  line  join  style  Is  defined  for  subsequent  line  elements.  The  line 
join  style  defines  the  appearance  of  Interior  vertices  of  polyline 
elements  and  of  compound  line  elements.  The  defined  styles  are; 

miter  join:  the  outer  edges  of  the  two  adjoining  line  segments  are 
extended  until  they  meet  at  a  point. 

round  join:  a  circular  arc  with  diameter  equal  to  the  line  width  is 
drawn  around  the  vertex  between  the  adjoining  segments  and  is  tilled 
In,  producing  a  rounded  corner. 

bevel  join;  the  adjoining  line  segments  are  terminated  wi:n  3  butt 
cap,  and  the  resulting  triangular  notch  is  filled  In. 

References: 


5.7.x  EDGE  CAP 
Parameters: 

edge  cap  Indicator  (one  of;  autt.  round,  projecting  square)  (E) 
Description: 

The  edge  cap  style  Is  defined  for  subsequent  edge  elements.  The  edge  caa 
style  determines  the  appearance  of  open  endpoints  of  filled  area  edges 
(such  as  may  result  from  a  mixture  of  visible  and  invisible  edge 
segments).  The  defined  styles  are: 
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butt  cap:  tha  edge  Ls  squared  off  ac  the  vertex,  there  Is  no 
projection  beyond  the  endpoint. 

round  cap:  a  semicircular  arc  with  diameter  equal  to  the  edge  width 
is  drawn  around  the  endpoint  and  filled  in.  Tha  drawn  edge  thus 
projects  beyond  tha  endpoint. 

projecting  square  cap:  the  edge  is  squared  off  at  a  distance  equal  to 
half  the  edge  width  beyond  the  endpoint. 

Kaf erances: 


5.7.x  EDGE  JOIN 
Paramatars: 

edge  join  Indicator  (one  of:  miter,  round,  bevel)  (£) 

Daseripcion: 

The  edge  join  style  is  defined  for  subsequent  filled  elements.  The  edge 
join  style  defines  the  appearance  of  interior  vertices  of  filled  area 
elements.  The  defined  styles  are: 

miter  join:  the  outer  edges  of  the  two  adjoining  edge  segments  are 
extended  until  they  meet  at  a  point. 

round  join:  a  circular  arc  with  diameter  equal  to  the  edge  width  Is 
drawn  around  the  vertex  between  the  adjoining  segments  and  is  filled 
in,  producing  a  rounded  corner. 

bevel  join:  the  adjoining  edge  segments  are  terminated  with  a  butt 
cap,  and  the  resulting  triangular  notch  is  filled  in. 

References : 


5.7.x  MITER  LIMIT 
Parameters : 

filter  limit  (R) 

Description: 

.Mitered  corners  can  extend  very  far  beyond  the  line  vertex  if  the  angle 
between  the  adjoining  Line  segments  is  small.  Miter  length  is  detinec  to 
be  the  distance  from  the  point  at  wnlch  the  inner  edges  of  the  adjoln-.ng 
.ine  segments  meet  to  the  point  ac  which  t.ne  outer  edges  meet.  If  miter 
length  exceeds  tne  miter  limit  aararaeter,  then  the  joining  line 
segments  are  rendered  with  a  oevex  join  instead  of  a  miter  join. 

Miter  limit  is  measured  as  a  scale  factor  applied  to  the  current  line 
width.  Miter  limit  applies  to  line  elements  and  edges  of  filled  areas 


References: 
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5.7.x  EXTERNAL  SYMBOL 
Paranatars: 

To  be  determined. 

Description:  ^ 

Reference  to  external  defined  symbol  Libraries  is  provided.  i he 

mechanism  of  this  element  is  yet  to  be  defined. 

Page  95 

Sub-clause  5.  7.  32:  Add  the  following  at  the  end  of  the  thi 
paragraph  of  the  description: 

.Vote  that  COLOUR  PRECISION  only  applies  to  direct  colour  model  values 


ANSI  X3H3 


Information  Processing  Systems  — 

Computer  Graphics  — 

Metafile  for  the  Storage  and  Transfer 
of  Picture  Description  Information 


Part  2 


Character  Encoding 


Addendum  3 

Draft  Document  l-L 

June  21 1  1988 

« 
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Clause  5,  Table  1:  Add  the  following  opcodes  to  Table  1: 


TABLE  1-  Opcodes  for  Metafile  Elements. 


Opcode 

7-3lt 

Coding 

3-Bit 

Coding 

FONTMETRIC  DEFINITION  opcode 

3/1 

3/0 

03/1 

03-0 

CHARACTER  KERNING  MODE  opcode 

3/1 

3/1 

03/1 

03/ 1 

CHARACTER  KERNING  TABLE  opcode 

3/1 

3/2 

03/1 

03/2 

FCS  TYPE  opcode 

3/1 

3/3 

03/1 

03/3 

FCS  INTEGER  PRECISION  opcode 

3/1 

3/4 

03/1 

03/4 

FCS  REAL  PRECISION  opcode 

3/1 

3/5 

03/1 

03/5 

FCS  EXTENT  opcode 

3/1 

3/6 

03/1 

03/  6 

CAP  HEIGHT  opcode 

TBD 

TBD 

3EGIN  COMPOUND  LINE  opcode 

3/3 

3/  6 

03/  3 

03  6 

END  COMPOUND  LINE  opcode 

3/3 

3/7 

03/3 

03.  ' 

BEGIN  COMPOUND  TEXT  PATH  opcode 

3/3 

3/3 

03/3 

03-  3 

END  COMPOUND  TEXT  PATH  oocode 

3/3 

3/9 

03/3 

03  9 

BEGIN  CLIP  REGION  oocode 

3/3 

3/10 

03/3 

03  10 

END  CLIP  REGION  opcode 

3/3 

3/11 

03/3 

03  '  11 

BEGIN  SHIELD  REGION  opcode 

3/3 

3/12 

03/  3 

03  12 

END  SHIELD  REGION  opcode 

3/3 

3/13 

03/3 

03  13 

SHIELDING  INDICATOR  opcode 

3/3 

3/14 

03/3 

03.  1- 

CONIC  ARC  opcode 

•  Hk 

3/0 

03/4 

03/0 

CONIC  ARC  TRANSFORMATION  opcode 

Ilk 

3/1 

03/4 

03/  1 

PARAMETRIC  SPLINE  CURVE  opcode 

3/4 

3/2 

03/4 

03.  2 

RATIONAL  B-SPLINE  CURVE  opcode 

3/4 

3/3 

* 

03/4 

03/  3 

COMPRESSED  PEL  ARRAY  opcode 

3/<. 

3/4 

03/- 

03.  - 

PEL  ARRAY  CLIP  RECTANGLE  opcode 

3/4 

3/5 

03/4 

03.  5 

LINE  TYPE  DEFINITION  opcode 

3/6 

3/4 

03/6 

03.  - 

hatch  style  definition  opcode 

3.' 6 

3/5 

03/  6 

03.  5 

LINE  Cap  opcode 

3  /  6 

3/6 

03.  6 

33  6 

LINE  JOIN  opcode 

3/6 

3/' 

036 

03  ■ 

EDGE  Cap  opcode 

3/6 

3/3 

03/  6 

03  3 

EDGE  JOIN  opcode 

3/6 

3/9 

03/6 

03  ^ 

.MITER  LIMIT  oocode 

3/6 

3/  LO 

03/6 

03.  10 

external  symbol  oocode 

3/.6 

J  '  .  • 

01  '  'b 

0  3  11 

Page  jJ 

Subclause  3.2:  Add  the  fallowing  alemenz  representations: 

3.2.x  rONTMETRIC  DEFINITION 

^  rONTMETRIC-OEr  irilTION-oocode:  3/ I  3."3> 

'integer:  font-i.ndex> 

'x.xxxx:  cnar3cter-inde.x> 

<xxxxx:  lef t -bear  I  ng> 

<xxxxx:  r ignt-bearlng> 

<xxxxx:  character-height) 

'xxxxx:  base L  ine-of f sec > 
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8.2.x  CHARACTER  KERNING  MODE 

<CHARACTER-ltERNING-MODE-opcoda:  3/1  3/l> 
cenumaraced:  character-kernLng>(node> 

<enuniarat8d:  oharacter-karning-moda>  ■  < Integer:  0>  (NONE) 

1  <lnteger:  1>  (PAIR) 

1  <inceger:  2>  (SECTORED) 

8.2.x  CHARACTER  KERNING  TABLE 

<CHARACTER-KERNING-TABLE-opcode:  3/1  3/2> 

<xxxxx:  to  be  determined) 

a. 2.x  PCS  TTPE 

<FCS-TVPE-opcode:  3/1  3/3> 

<enumarated:  FCS-type> 

<enumaratad:  FCS-type>  -  <lnteger:  0>  (INTEGER) 

:  <lnteger:  1>  (REAL) 

1  <tnteger:  2>  (VDC) 

8.2. x  FCS  INTEGER  PRECISION 

<FCS-INTECER-PR£CISION-opcode:  3/1  3/4> 

<lnteger:  largest-lrteger-code  ♦  1> 

The  largeat-lnteger-code  tells  how  many  bits  occur  In  the  largest  posibl 
magnitude  for  an  Integer.  For  example.  If  integers  In  the  metafile  can 
range  from  -32767  to  *32767,  the  largest-lntegar-code  Is  15.  One 
adlclonal  bit  is  required  for  the  sign,  and  so  Is  added  to  obtain  the 
proper  precision.  Thus  In  this  example  the  parameter  would  be  16. 

3.2. x  FCS  REAL  PRECISION 

<.^CS-R£AL-PR£CISION-opcode:  3/1  3/5> 

<lnteger:  largest-real-code  *  1> 

< Integer:  smallest-real-code> 

< Integer;  default-exponent-for-real3> 

(enumerated:  exponents-allowed> 

(enumerated;  exponent3-allowed>  -  (Integer;  0>  'allowed) 

I  (Integer:  1>  (forbidden) 

See  3.  2.  5  of  ANSI  X3.  122-1986  for  a  description. 

3.2.x  FCS  EXTENT 

(."CS-EXTENT-opcode;  3/1  3/6> 

'fcspolnt:  f I rst -corner> 

(fcspolnt;  second-corner> 

(fcspolnt)  ::■  ( Integer) ( Integer) 

I  (real)(real) 


where  a  point  list  is  encoded  such  that  the  first  point  Is  absolute  -i:- 
font  coordinate  space  and  each  of  the  following  points  Is  relative  to 
previous  one. 
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3.2.x  CAP  HEIGTH 

<T3D> 

Page  >*0 

Subclause  3.  ■4;  Add  ehe  following  element  representations 

3.4.x  BEGIN  COMPOUND  LINE 

<BEGIN-COMPOUND-LINE-opcode:  3/3  3/6> 


3.4.x  END  COMPOUND  LINE 

<EMD-COMPOUND-LINE-opcoda:  3/3  3/7> 

3.4.x  BEGIN  COMPOUND  TEXT  PATH 

<3EGIN-CCMPOUND-TEXT-PATH-opcode:  3/3  3/3> 

3.4.x  END  COMPOUND  TEXT  PATH 

<END-COMPOUND-TEXT-?ATH-opcode:  3/3  3/9> 

3.4.x  BEGIN  CLIP  REGION 

<BEGIN-CLIP-R£GIOM-opcod«:  3/3  3/10> 

3.4.x  END  CLIP  REGION 

<£NO-CLIP-RECION-opcode:  3/3  3/ll> 

3.4.x  BEGIN  SHIELD  REGION 

<BECIN-SHIELD-RECION-opcoda:  3/3  3/L2> 

3.4.x  END  SRILD  REGION 

<£ND-SaiEL3-REQ:ON-opcod«:  3/3  j/13> 

3.4.x  SHIELDING  INDICATOR 

<SHIELDINC-I.'IOICATOR-opcode:  3/3  3/14> 

< enumerated:  3hleldlng-lndLcator> 

^enumerated:  shielding- Indicator >  »  <intager:  0>  loffi 

;  <integer:  1>  toni 


* 


228 


CCM  Addenduo  3  Character  Encoding  Spec*  VI. 0  June  20 •  1988 
P3ge  ^2 

Subclsuse  3.5:  Add  the  folloving  elemmmt  representations: 

8.5. X  CONIC  AKC 

<C0NIC-ARC-opcode:  3/^.  3/0) 

<poinc;  start-point) 

<potnt:  end-point) 

<r8al;  f Irst-param) 

<real:  second-param> 

<reai:  thlrd-param) 

<reai:  fourth-param) 

<real:  f If th-parao) 

<raal:  slxth-param) 

3.5. x  CONIC  ARC  TRANSrORMATION 

<CONIC-ARC-TIlANSFORMATION-opcode:  3/4  3/1) 

<VDC:  Rll) 

<VDC:  Ri2) 

<VDC;  R21) 

<VDC:  R22) 


3.5. X  PARAMETRIC  SPLINE  CURVE 

<PARAMETRIC-SPLIME-CURVE-opcoda:  3/4  3/2) 

< Integer:  curve-type) 

< Integer:  H-degree-o£-cont lnulty> 

< Integer:  N-nuaber-of-segmentS) 

<??■????????) 

<??????????  ) 

<7?????????  ) 

3.5. x  RATIONAL  B-SPLINE  CURVE 

<RATIONAL-a-SPLINE-CURVE-opcode;  3/4  3/3) 

< Integer;  upper-lndex-o£-sums) 

< Integer;  M-degree-of-the-basls-funct Ion) 

<anumeratad:  curve-open-flag) 

<  enumerated:  equat lon-type-£ lag) 

<enumerated:  periodic-flag) 

<7?77'’7????77) 

<??7????7????  ) 

<777?7?7???77> 

<reai;  start-param) 

<reai:  end-parara) 

<enumer3ted:  curve-open-flag)  •  (Integer;  0)  'OPEN) 

'Integer:  1>  'CLCScDi 

^enumerated;  aquation-type-flag)  -  (Integer;  0)  (XATIONALi 

1  (integer:  L>  i POLVMCMIAL i 

(enumerated:  per  lod  ic- f  Lag  >  ■  (integer;  0>  '  ,UCM-?ER:ODIC  i 

1  (integer;  L>  ''PERIODIC: 
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3-5-Z  COMPRESSED  PEL  ARRAY 

<COMPRESSED-PEL-ARRAY-opcode:  3/4  3/4> 

<enuineraced:  T-encodlng> 

<enumerated:  P-pel-path> 

(enumerated:  L-l Lne-progress ion> 

<reai:  S-pei-spac lng> 

<reai:  spac Ing-rat io> 

(Integer:  M-number-of-pels-per-llne> 

(integer:  NL-number-o£>L ines> 

(xxxxxxx:  pel-array> 

(enumerated:  T-encodlng>  ■  (Integer:  0>  (T4) 

!  (integer;  1>  iT6i 

(enumerated:  ?-pei-path>  -  (integer:  0>  (0-DECREESl 

I  (integer:  I>  f90-DEGREESl 

I  (integer:  2>  ( 130-DEGREES  1 

!  (integer:  3>  ( 2V0-DEGREES I 

(enumerated:  L-L ine-progress ion>  ■  (integer:  0>  (90-0ECREE 

:  (integer:  1>  (270-0EGRE 


3.5.x  PEL  ARRAY  CLIP  RECTANGLE 

(PEL-ARRAY-CLIP-RECTANGLE-opcode:  3/4  3/5> 
(integer:  Xl> 

(integer:  Yl> 

(integer:  X2> 

(integer:  Y2> 

(point;  f irst-corner> 

(point:  second-corner> 
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Subclause  8.  6:  Add  cbe  following  element  represencat ions: 

a. 6.x  LINE  TYPE  DEPINITION 

(LIME-TYPE-DEFINITION-opcode:  3/6  3/4> 

(integer:  line-type)  (enumerated:  dash-unit-selector> 

(real:  dash-repeat-length> 

(enumerated:  adaptive-flag) 

<  integer;  list-of-dash-elements>« 


(enumerated:  dash-unit -selector) 


(integer:  0) 
(integer;  L) 
(integer:  1) 
(integer:  1) 


I  70C I 
I  mm  I 

'native  device  un 
f  aostract ' 


(enumerated:  adaptive-flag)  ■  (integer;  0)  (NO) 

!  (integer;  L )  (YES ) 
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8.6.x  HATCH  STYLE  DEFINITION 


<HATCH-STYL£-DEFINITION-opcode:  3/6  3/5> 
< integer:  hatch-lndex> 

<enumerated:  style-indlcatoo 
< enumerated:  hatch-space-untts-selector> 
<real:  DX-vector> 

<real:  DY-vector> 

<reai:  duty-cycle-langth> 

< integer:  list-of-hatch-elements>* 


(enumerated:  adaptlve-flag>  -  (integer:  0>  (parallel) 

1  (integer:  1>  (cross-hatch) 


(enumerated: 


hatch-space-units-selec  too 


•  (integer; 

o> 

( VDC ) 

i'  (integer; 

i> 

( mm) 

;  (integer: 

1> 

(native  device 

units ) 

!  (integer: 

1> 

(abstract ) 

8. 6.x  LINE  CAP 


(LINE-CAP-opcode:  3/6  3/6> 
(enumerated:  line-cap-indicator> 


(enumerated:  line-cap-indicator> 


(integer:  0> 
(integer:  1> 
(integer:  2> 


(butt) 

! round ) 

(projecting  square) 


8.6.x  LINE  JOIN 

(LINE-JOIM-opcode;  3/6  3/7> 

(enumerated:  line- join- indica  too 

(enumerated:  line- join-indicatoo  ■  (integer:  0>  (miter) 

i  (integer:  1>  (round) 

!  (integer:  2>  i bevel ' 


3.6.x  EDGE  CAP 

( EOCE-CAP-opcode:  3/6  3/3> 

(enumerated:  edge-cap-indicatoo 

(enumerated;  edge-c3p-indtcator>  »  (integer:  0)  (butt) 

( integer:  1 >  : round ) 

(integer;  2>  (projecting  sauare' 

3.6.x  EDGE  JOIN 

(EDCE-JOIN-opcode:  3/6  3/9> 

(enumerated;  edge-joln-lndicator> 

(enumerated:  edge- join- indicator >  •  (integer;  0>  (miter) 

'  (integer;  L  >  i round ) 

)  ( integer:  2  >  ( bevel ) 
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8.6.x  MITER  LIMIT 

<MITER-LIMIT-opcode:  3/6  3/10> 

<real:  nilter>llmtc> 


8.6.x  EXTERNAL  SYMBOL 

<EXTERNAL-SYMBOL-opcode:  3/6  3/ll> 
<■’?????????  > 
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Pagt  LOO 

Clausa  6;  Add  eJie  following  dafaulz  spec  if  icac  ions: 


CONIC  ARC  TRANSFORMATION  MATRIX: 
PEL  ARRAY  CLIP  RECTANGLE: 

PEL  ARRAY  REFERENCE  POINT: 

Conpound  Line 

(BEGIN/ END  COMPOUND  LINE) 

Compound  Text  Path 

(BEGIN/ END  COMPOUND  TEXT  PATH) 

Clipping  Region 
(BEGIN/ END  CLIP  REGION) 

Shielding  Region 
(BEGIN/ END  SHIELD  REGION) 

CLIP  INDICATOR 

SHIELD  INDICATOR 

COLOUR  REPRESENTATION  METHOD 


identity  matrix 

(0,0)  upper  left,  (N-1,L-1)  lower 
right,  where  N  is  the  number  of 
pels  per  line,  and  L  is  the  numbe 
of  lines  in  the  last  COMPRESSED  P 
ARRAY  element. 

upper  left-hand  corner  point  of  the 
default  VDC  extent 

No  default 

Right 

VDC  Extent 

VDC  Extent 

On 

Off 

RGB 


« 
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Psge  21 

Subclause  7.3:  Add  the  following  notes  (on  Table  •* ) : 

nn  FOMTMETRIC  DEFINITION:  has  5  paramecers: 

PI:  (integer)  font  index 
P2:  (xxxxx)  character  index 
P3:  (xxxxx)  left  bearing 
?<*:  (xxxxx)  right  bearing 
PS:  (xxxxx)  character  height 
P6:  (xxxxx)  baseline  offset 

nn  character  KERNINC  MODE:  has  I  parameter: 

PI:  (enumerated)  character  kerning  mode:  valid  values  are: 

0  NONE 

1  PAIR 

2  SECTORED 

nn  CHARACTER  KERNI.VG  TABLE:  format  to  be  determioed. 

rx:  (xxxxx)  to  be  determined 
nn  FCS  TYPE:  has  1  parameter: 

PI:  (enumerated). FCS  type:  valid  values  are: 

0  INTEGER 

1  REAL 

2  VOC 

nn  FCS  INTEGER  PRECISION:  has  I  parameter: 

PI:  (integer)  FCS  integer  precision:  3.  16.  l>* .  or  32  are  the  only  vallu 
values. 

nn  FCS  REAL  PRECISION:  has  3  parameters: 

Pi:  'enumerated)  form  of  representation  for  real  values:  valid  values 
are: 

0  floating  point  form 

1  fixed  point  form 

?2:  (integer)  field  width  for  exponent  or  whole  part  (including  1  hit 
for  sign) 

?3:  (integer)  field  width  for  fraction  or  fractional  part 
legal  tomoinations  of  values  are: 


p  t 

?2 

DT 

Result 

0 

9 

23 

3:-bit 

floating  noLnt 

0 

12 

52 

-b i t 

f loa ting  DO i nt 

1 

16 

16 

32-bit 

fi:<?d  point 

L 

32 

• 

ow-bi  t 

fixed  point 

« 
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nn  FCS  EXTENT:  has  2  paramacers: 

PI:  (fespoint)  first  corner 
P2:  (fespoint)  second  corner 

If  PCS  TYPE  is  real,  default  FCS  EXTENT  Is  (0.0.  0.0). 

(0.  9999.  .  .  ,0.  9999.  .  .  ). 

If  FCS  TYPE  Is  INTEGER,  default  FCS  TYPE  Is  (0,0),  (32767.  32 
nn  CAP  HEIGTH:  Parameterization  to  be  determined. 

•««  Additional  work  required  **« 


?3ge  26 

Subclause  7.  5:  Add  Che  following  notes  C on  Table  6J: 
nn  BEGIN  COMPOUND  LINE:  has  no  parameters, 
nn  END  COMPOUND  LINE:  has  no  parameters, 
nn  BEGIN  POUND  TEXT  PATH:  has  no  parameters, 
nn  END  -OMPOUND  TEXT  PATH:  has  no  parameters, 
nn  BEGIN  CLIP  REGION;  has  no ' parameters, 
nn  END  CLIP  REGION:  has  no  parameters, 
nn  BEGIN  SHIELD  REGION:  has  no  parameters, 
nn  END  SHILD  REGION:  has  no  parameters, 
nn  SHIELDING  INDICATOR;  hs  1  parameter: 

PI:  (enumerated)  shielding  indicator;  valid  values  are: 

0  OFF 

1  ON 
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Subclause  7.6:  Add  Che  folloving  notes  Con  Table  ~ 1  : 


CONIC  ARC:  has  3  parameters; 


?1 

(point) 

?2 

f point ) 

P3 

( real ) 

P<. 

( real ) 

P5 

( real ) 

P6 

( real ) 

P7 

( rea i  ) 

P8 

( real ) 

start  point 
end  point 
first  param 
second  param 
third  param 
fourth  param 
fifth  param 
sixth  param 


« 
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nn  CONIC  ARC  TRANSFORMATION:  has  <*  paramacers: 

PI:  (VDC)  Rll 
P2:  (VBC)  R12 
P3:  (VDC)  R21 
?U:  (VDC)  R22 

nn  PARAMETRIC  SPLINE  CURVE:  has  6  parameters: 

PI:  (Integer)  curve  type 
P2:  (Integer)  H  degree  of  continuity 
P3:  (integer)  N  number  of  segments 
PA:  (??????????) 

P5:  (??????????) 

P6:  (??????????) 

nn  RATIONAL  S-SPLINE  CURVE:  has  10  parameters: 

PI:  (integer)  upper  index  of  sums 

P2:  (Integer)  M  degree  of  the  basis  function 

?3:  (enumerated)  curve  open  flag;  valid  values  are: 

0  OPEN 

1  CLOSED 

PA:  (enumerated)  equation  type  flag:  valid  values  are; 

0  RATIONAL 

1  POLYNOMIAL 

PS:  (enumerated)  periodic  flag:  valid  values  are; 

0  NON  PERIODIC 

1  PERIODIC 


P6: 

) 

P7; 

(•  T T  T  ■» -» 

) 

P8: 

) 

P9; 

(real)  start 

param 

PIO; 

(real)  end  param 

nn  COMPRESSED  PEL  ARRAY:  has  3  parameters: 

PI:  (enumerated)  T  encoding:  valid  values  are: 

0  TA 

1  T6 

?2;  '’enumerated)  ?  pel  path:  valid  values  are: 

0  0  DECREES 

1  90  DECREES 

2  130  DEGREES 

3  270  DECREES 


« 
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nn 


?3:  (enumerated)  L  line  progression:  valid  values  are: 

0  90  DEGREES 

1  270  DEGREES 

Pi:  (real)  S  pel  spacing 

PS:  (real)  spacing  ratio 

P6:  (Integer)  M  number  of  pels  per  line 

P7:  (Integer)  NL  number  of  lines 

P8:  (xxxxxxx)  pel  array 

PEL  ARRAY  CLIP  RECTANGLE:  has  6  parameters: 

PI:  (Integer)  XI 

P2 :  ( Integer )  Y1 

?3:  (Integer)  X2 

Pi :  ( Integer )  Y2 

PS:  (point)  first  corner 

P6:  (point)  second  corner 
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Subclause  7.  Add  the  fallowing  notes  ( on  Table  3): 
nn  LINE  TYPE  DEFINITION:  has  5  parameters: 

PI:  (Integer)  line  type 

P2:  (enumerated)  dash  unit  selector:  valid  values  are: 

0  VDC 

1  MM 

2  NATIVE  DEVICE  UNITS 

3  abstract 

P3:  (real)  dash  repeat  length 

pi;  (enumerated)  adaptive  flag:  valid  values  are: 

0  NO 

1  YES 

PS;  (Integer)  list  of  dash  elements 
nn  HATCH  STYLE  DEFINITION:  has  7  parameters: 

PI:  (Integer)  hatch  Index 

?2;  (enumerated)  style  Indicator:  valid  values  are: 

0  PARALLEL 

1  CROSS  hatch 

P3:  (enumerated)  naten  space  units  selector:  vaiii  values 

0  7  DC 

1  MM 

2  NATIVE  DEVICE  UNITS 

3  ABSTRACT 


ar 


239 


CCM  Addandum  3  ainar7  Encoding  Sp«e.  VI. 0  June  20,  1938 

Pi»:  (real)  DX  vector 

P5:  (real)  DY  vector 

P6:  (real)  duty  cycle  length 

P7;  (Integer)  list  of  hatch  elements 

nn  LINE  CAP:  has  1  parameter: 

PI:  (enumerated)  line  cap  indicator:  valid  values  are; 

0  BUTT 

1  ROUND 

2  PROJECTING  SQUARE 
nn  LINE  JOIN:  has  1  parameter: 

PI:  (enumerated)  line  join  indicator;  valid  values  are: 

0  MITER 

1  ROUND 

2  BEVEL 

nn  EDGE  CAP;  has  1  parameter; 

PI;  (enumerated)  edge  cap  indicator:  valid  values  are: 

0  MITER 

1  ROUND 

2  BEVEL 

nn  EDGE  JOIN:  has  1  parameter: 

PI:  (enumerated)  edge  join  Indicator;  valid  values  are; 

0  MITER 

1  ROUND 

2  BEVEL 

nn  MITER  LIMIT;  has  I  parameter; 

PL:  (real)  miter  limit 
nn  external  SYMBOL:  has  i  parameter: 

PI:  (??????????) 
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?3ge  1 1 


Subcisuse  3.4.1:  Add  the  foLloving  words  to  the  deleted  words  list: 


I 

I 


CURVE 

MATRIX 


Psge  1 1 

Subclause  5.  4.  3:  Add  the  following  words  to  the  unabbreviated  words 
list: 

CAP 

CONIC 

EXTERNAL 

JOIN 

LIMIT 

MITER 

PEL 

REGION 

SHIELD 

SPLINE 

SYMBOL 
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Subclause  5.  4.  4:  Add  the  following  abbreviations: 


I 

t 

I 

fl 

I 


COMPRESSED  CMPRSD 

COMPOUND  CMPD 

DEFINITION  DBF 

KERNING  KERN 

RATIONAL  RATNL 

TRANSFORMATION  TRAN 


I 

I 
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Subclause  5.  4.  5:  Add  the  following  derived  element  names: 


Metafile  Name 

Element  Name 

BEGIN  COMPOUND  LINE 

BEGCMPDLINE 

END  COMPOUND  LINE 

ENDCMPDLINE 

BEGIN  COMPOUND  TEXT  PATH 

BECCMPDTEXTPATH 

END  COMPOUND  TEXT  PATH 

ENOCMPDTEXTPATH 

BEGIN  CLIP  REGION 

BECCLIPREGION 

END  CLIP  REGION 

ENDCLIPRECICN 

BEGIN  SHIELD  REGION 

3ECSHIELDREGION 

END  SHIELD  REGION 

ENDSHIELORECICN 

SHIELDING  INDICATOR 

SHIELD 

rONTMETRIC  DEFINITION 

FONTMETRICDEF 

character  kerning  MODE 

CHARKERNMODE 

CHARACTER  KERNING  TABLE 

charkerntable 

FCS  TYPE 

FCSTYPE 

rCS  INTEGER  PRECISION 

FC3INTECERPREC 

FCS  REAL  PRECISION 

FCSREALPREC 

FCS  EXTENT 

FCS EXT 
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CAP  HEIGHT 

TBD 

LINE  TYPE  DEFINITION 

HATCH  STYLE  DEFINITION 

LINE  CAP 

LINE  JOIN 

EDGE  CAP 

EDGE  JOIN 

MITER  LIMIT 

EXTERNAL  SYMBOL 

LINETYPEDEF 

HATCHSTYLEDEF 

LINECAP 

LINEJOIN 

EDGECAP 

EDGEJOIN 

MITERLIMIT 

EXTERNALSYMBOL 

CONIC  ARC 

CONIC  ARC  TRANSFORMATION  MATRIX 
PARAMETRIC  SPLINE  CURVE 

RATIONAL  B-SPLINE  CURVE 

CONICARC 

CONICARCTRAN 

PARAMETRICSPLINE 

RATNLBSPLINE 

COMPRESSED  PEL  ARRAY 

PEL  ARRAY  CLIP  RECTANGLE 

cmprsdpelarray 

PELARRAYCLIPRECT 

Page  15 

Subcl3us0  6.2:  Add  the  following  Kecafile  Desccipcer  element 
encodings: 


FONTMETRIC  DEFINITION  :  ;  .  FONTMETRICCEF 

<1: F0NTINDEX>  (positive  I 

(format  to  be  determined) 

<TERM> 

CHARACTER  KERNING  MODE  CHARKERNMODE 

<S0FTSE?> 

<N0NEI pair; SECTORED^ 

<TERM> 


character  KERNING  TABLE 


FCS  TYPE 


"CC  INTEGER  PRECISION 


FCS  REAL  PRECISION 


CHARKERNTA3LE 

(format  to  be  determined) 

<TERM> 

FCS TYPE 

<30FTSE?^ 

< integer; real ; ydc  > 

; rERM> 

FGSINTEGERPREC 

'S0FTSE?> 

< I: MININT> 

<SEP'> 

< I: MAXINT> 
vrERM> 

FCSREALPREC 
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<S0FTSEP> 

<F: MINREAL) 

<SEP> 

<F: MAXREAL> 

<SEP> 

<1: DIGITS) 

<TERM> 


FCS  EXTENT  :  -  FCSEXT 

<S0FTSEP> 

<P; FIRSTCORNER) 
<SEP> 

<P: SECONDCORNER) 
<TERM> 


CAP  HEIGHT 


T3D<TERM> 


Page  18 

Subclause  6.  5:  Add  che 
BEGIN  COMPOUND  LINE 
END  COMPOUND  LINE 
BEGIN  COMPOUND  TEXT  PATH 
END  COMPOUND  TEXT  PATH 
BEGIN  CLIP  REGION 
END  CLIP  REGION 
BEGIN  SHIELD  REGION 
END  SHIELD  REGION 
SHIELDING  INDICATOR 


follaving  Control  element  encodings: 

aECCMPDLINE<TERM> 

:  ;  -  ENDCMPOLINE<TERM> 

3ECCMPDTEXTPATH<TERM> 

:  :  .  ENDCMPDTEXTPATH<TERM> 

;  :  .  BECCLIPREGION<TERM> 

ENDCLIPRECION<TERM> 

BECSHISLDR£CICN<TERM> 

ENDSHIELDREGICN<rERM> 

SHIELD 

<SOFTS£?> 

<off:on> 


Page  19 

Subclause  6.6:  .Add  the  following  Gcaanical  Primitive  element 
encodings: 

CONIC  ARC  : : -  CCNICARC 

■ 30FT3E?) 

<  ?;  3TART?Or;iT> 

<SE?) 

^?; ENDPOINT) 

<SEP> 

cF; FTRSTPARAM) 

<SEP> 

<F; SECONDPARAM) 

<SEP) 
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<F;THIRDPARAM> 

<SEP> 

<F:  FOURTH? A1UM> 

<SEP> 

cF; FIFTHPARA«> 

<SEP> 

<F:  SIX7HPARA11> 

<TERM> 

CONIC  ARC  TRANSFORMATION  MATRIX  : : -  CONICARCTRAN 

<SOFTSEP> 

<VDC:R11> 

<SEP> 

<7DC-R12> 

<SEP> 

<VDC: R21> 

<SEP> 

<VDC;R22> 

<SEP> 

<P:COORDOFFSET> 

<TERM> 

parametric  spline  curve  :  :  -  PARAMETRICSPLINE 

<SOFTSEP> 

<I:CURVETYPE> 

<SEP> 

< I : CONTINUITYDEGREE  > 
<SEP> 

<I:NUMSECMENTS> 

<SEP> 


<TERM> 

RATIONAL  B-SPLINE  CURVE  :  ;  -  RATNL3SPLINE 

<SOFTSEP> 

<1: UPPERINDEXOFSUM> 
<SEP> 

<OPEN!CLOSED> 

<5EP> 

< RATIONAL  I P0LTN0MIAL> 
<SEP> 

<NONPERIODIC: PERIODIC) 
<SE?> 


<SEP> 

<F: START?ARAM> 
<SE?> 

<?: END P ARAM > 
<TERM> 

COMPRESSED  PEL  ARRAY  :  ;  .  CMPRSDPELARRAY 

<S0FTSEP> 

<T4 : T6> 

<SEP> 

<0:901 1301 2T0> 
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PEL  ARRAY  CLIP  RECTANGLE 


<SEP> 

<901270> 

<SEP> 

<F:  PELSPACING) 
<SEP> 

<F;  SPACINGRATIO> 
<SEP> 

<1: PELSPERLINE> 
<SEP> 

<I:NUMBEROFLIMES> 

<SEP> 

(?????????????  ) 


<TERM> 

PELARRAYCLIPRECT 

<S0FTSEP> 

<I:X1> 

<SEP> 

<1: Yl> 

<SEP> 

<I:.X2> 

<SEP> 

<1: Y2> 

<SEP> 

<P: FIRSTCORNER> 
<SEP> 

<P: SECONBCORNER) 
<TERM> 


P3g9  2^ 


Subclause  6.  7:  Add  the  Sollouing  At  trlbu  ce  element  encodings 

LINE  TYPE  DEFINITION  LINETYPEDEF 

<SOFTSEP> 

<1: LINETYPE> 

<SEP> 

<VDC;«M1 NDU: abst> 

<SE?> 

<F: DASHREPEATL£N> 

<SEP> 

<NOt YES> 

<SEP> 

<TERM> 

HATCH  STYLE  DEFINITION  HATCHSTYLE3EF 

<SOFTSE?> 

<1: HATCHINDEX> 

<SEP> 

(Parallel: CROSSHATCH > 
<SEP> 

(VDCIMMINUU: ABST> 

<SEP> 


246 


CCM  Addtndu*  3  Cl«af  Taxt  Encoding  Spac-  VI. 0  Juna  20 i  1988 

<F; DX> 

<SEP> 

<F: DY> 

<SEP> 

<F: 0UTYCYCL£> 


I?????????????' > 


<TERM> 


LINE  CAP 


LINECAP 

<SOFTSEP> 

<  BUTT : ROUND  I  SQUARE  > 
<TERW> 


line  join 


LINEJOIN 

<SOFTSEP> 

<MITER! ROUND  1 BEVEL> 
<TERM> 


EDGE  CAP 


EDGECAP 

<SOFTSEP> 

< BUTT! ROUND! SQUARE > 
<TERM> 


EDGE  JOIN  : : -  EDGEJOIN 

<SOFTSEP> 

.  <MITERI ROUND! BEVEL) 
<TSRM> 

MITER  LIMIT  : : -  MITERLIMIT 

<SOFTSEP> 

<F: MITERLIMIT) 
<TERM> 

EXTERNAL  SYMBOL  :  :  •  S.XTERNALSYMBOL 

I  to  be  determined l 


<TERM> 
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METAFILE  REFERENCE  MODEL  AMD  POSITIONS 
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X3H3/88-77 


A  Reference  Model 
to  Aid  in  Understanding 
the  Role  of  Multiple  Metafile  Types 

U.S.  Position 

17  May  1988 


I.  Motivation 

Considering  the  current  set  of  graphics  standards  completed  and  in 
progress,  and  the  current  set  of  proposals  for  Addenda  to  IS  8632, 
there  appears  to  be  a  pressing  need  for  a  useful  reference  model  with 
which  to  understand  the  different  varieties  of  metafile  and  how  and  where 
they  fit  into  graphics  systems. 

'  The  relative  newness  of  the  Addendum  process  within  SC24  has  led  us  to  a 
situation  where  there  is  much  confusion  and  lack  of  clarity  with  respect 
to  the  scope  and  goals  of  the  CGM  Addenda. 

We  hope  that  this  contribution  wilt  prove  to  be  a  useful  reference  model 
for  re-evaluating  the  Addenda  in  progress,  for  aligning  their  functionality 
with  the  appropriate  standards,  and  as  an  input  for  the  Reference  Models 
group  for  future  work. 

II.  Model  and  Definitions 

A.  Types  of  Metafiles.  We  believe  it  is  useful  to  distinguish  between 
two  fundamentally  different  types  of  metafile  (see  Diagram  1); 

Interface  or  Session  Capture  -  this  type  of  metafile  is  intimately 
bound  to  the  semantics  of  a  particular  interface,  as  defined  in  a  semantic 
standard.  This  kind  of  metafile  is  frequently  referred  to  as  an  audit  inii. 

For  example,  the  GKSM  is  a  session  capture  metafile  which  captures  the 
information  flowing  across  the  workstation  interface  defined  by  GKS. 

Static  State  Capture  -  this  type  of  metafile  is,  in  effect,  a  "snapshot". 

For  example,  the  PHIGS  archive  file  is  a  snapshot  of  the  state  of  zero  or 
more  PHIGS  structures;  the  CGM  is  a  snapshot  of  a  picture  definition. 

The  state  capture  variety  of  metafile  need  not  be  as  tightly  bound  to  the 
semantics  of  the  generator  of  the  metafile  as  the  incerface  capture 
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Basic  Building  Blocks 
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Diagram  1 
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variety,  although  it  may  be.  For  example,  the  CGM  defines  "pictures"  which 
can  be  viewed  as  "things  unto  themselves",  comprising  sufficient 
information  that  they  may  be  generated  or  interpreted  by  a  variety  of 
different  graphics  systems  not  limited  to  those  based  on  API’s  defined  by 
SC24  graphics  standards.  Conversely,  the  PHIGS  archive  file  contains 
information  tightly  bound  to  the  semantics  of  the  PHIGS  standard,  and 
would  not  be  expected  to  be  used  by  clients  other  than  PHIGS 
implementations. 

B.  Reference  Model.  Diagram  2  illustrates  the  overall  metafile 
reference  model,  showing  ail  possible  locations  of  both  types  of  metafiles 
(session  capture  and  state  capture)  within  the  context  of  the  current 
layered  or  pipeline  model  used  in  this  generation  of  SC24  standards.  Not 
all  of  these  metafiles  need  be  defined  as  standards.  Also,  not  ail  graphics 
levels  (boxes),  interfaces  (connectors),  or  metafiles  need  be  explicitly 
present  in  an  implementation,  which  can  be  viewed  as  a  degenerate  case 
of  the  overall  reference  model.  Any  or  all  of  the  interfaces,  metafiles,  or 
processing  environments  may  be  replaced  by  equivalent  facilities  based  on 
proprietary  definitions  or  de  ^cto  standards,  without  invalidating  the 
overall  reference  model. 

Each  of  these  metafiles  has  a  distinct  set  of  semantics,  and  a  distinct 
purpose  and  use.  We  believe  that  the  graphics  standards  community,  and 
the  graphics  industry,  are  best  served  by  cleanly  defined  standards  which 
serve  exactly  one  of  these  purposes  as  represented  by  a  single  point  in  the 
model. 

Diagram  3  illustrates  how  this  basic  reference  model  could  be  applied  to  a 
layered  standards-based  graphics  system.  Note,  however,  that  it  is  only 
one  possible  arrangement. 


C.  Harmonization  of  Multiple  Metafile  Standards.  We  believe  that 
separate  metafile  standards  can  be  harmonized  through  use  of  common 
encoding  techniques,  deliberately  choosing  to  encode  identically  those 
elements  which  are  semantically  identical  in  these  standards. 

A  useful  analogy  can  be  drawn  to  language  bindings.  For  any  semantic 
standard,  language  bindings  can  be  generated  for  several  languages.  For 
any  language,  bindings  can  be  made  to  several  semantic  standards. 
Although  this  could  conceivably  have  led  to  a  wild  proliferation  of  binding 
techniques  and  inconsistent  choices,  the  chaos  has  been  managed  quite 
well  by  means  of  a  central  "generic  issues”  log  which  is  applied  to  all 
language  bindings,  and  by  a  commitment  to  harmonize  closely  related 
bindings  through  conscious  application  of  consistent  binding  techniques, 
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An  Instance  of  a  Layered  Architecture 
Based  on  the  Reference  Model 

(Diagram  3) 


NOTE:  there  is  no  implication  that  PHIGS  need  be  built 
on  top  of  CGI,  nor  that  CGM  be  generated  through  CGI. 


This  is  only  one  possible  arrangement,  for  illustration  only. 
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naming  and  abbreviation  conventions,  and  deliberate  reuse  of  components. 


Towards  this  end,  we  encourage  the  WG3  Metafile  Rapporteur  Group  to 
produce  documents  which  describe  the  encoding  techniques  developed  so 
far,  and  which  provide  guidance  in  how  to  apply  these  encoding  techniques 
to  generate  compatible  encodings  for  additional  metafile  standards. 

D.  The  question  of  multiple  usage,  it  is  not  always  the  case  that 
information  from  a  metafile  re-enters  the  same  system  from  whence  it 
came,  nor  is  it  necessanly  the  case  that  it  re-enters  the  system  at  the 
same  point  where  it  was  generated. 

It  should  be  recognized,  however,  that  when  either  of  these  situations 
occurs,  additional  software  processing  will  be  needed  to  map  the 
semantics  inherent  in  the  metafile  type  onto  the  semantics  available  for 
the  type  of  metafile  which  can  be  processed  by  the  interpreter.  This 
mapping  might  be  in  the  form  of  a  filter  which  turns  one  form  of  state 
capture  metafile  into  another  (e.g.,  taking  a  PHIGS  archive  file  and 
creating  CGM  files  for  picture  output),  or  an  emulator  which  can  take  a 
session  capture  metafile  and  "play  it  out"  over  a  different  interface  (e.g., 
taking  a  GKSM  and  feeding  it  into  a  PHIGS  workstation).  This  additional 
processing  may  also  happen  within  a  processing  environment;  for  example, 
a  PHIGS  implementation  might  support  Importing  CGM  picture  capture 
metafiles,  and  provide  the  necessary  interpretation  to  insert 
corresponding  PHIGS  elements  into  the  PHIGS  structure  store  (as 
described  in  Annex  H  of  the  PHIGS  standard).  More  than  one  such  mapping 
can  occur  for  any  given  pair  of  metafile  and  consumer  of  the  metafile. 
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U^.  Pomtion  on 
Strueturinc  and  Profraasion 
of  CGM  Addanda 


I.  Introduction 

The  U^.  baa  submitted  a  paper  entitled  "A  Reference  Model  to  Aid  in  Understanding  the  Role  of  Multi¬ 
ple  Metafile  Types',  document  X3H3/88*77.  These  comments  are  made  in  the  context  of  that  model. 

The  addendum  process  was  chosen  as  the  fastest  available  method  for  producing  a  standardized  GKSM 
based  on  the  CGM.  However,  a  consideration  of  the  three  addenda  in  process  reveals  that  the  lack  of  a 
NWI  ballot  to  agree  upon  scope  and  goals  has  created  more  problems  than  it  has  solved. 

The  U.S.  believes  it  is  inappropriate  to  use  the  addendum  process  to  alter  the  CGM  standard  in  ways 
that  change  the  metafile  type  (static  state  capture)  or  its  location  in  the  graphics  pipeline.  The  adden¬ 
dum  process  should  be  reserved  for  those 'additions  which  enhance  the  functionality  in  ways  consistent 
with  the  original  scope,  goals,  and  architecture  of  the  standard.  The  U.S.  believes  that  the  addendum 
process  should  not  be  used  as  a  general  means  of  building  quite  different  graphics  standards  under  the 
guise  of  a  modification  to  an  existing  standard. 


n.  Conaidoration  of  Addendum  1 

The  Metafile  Reference  Model  helps  clarify  the  relationship  of  addendum  1  to  ISO  8632.  There  are  at 
least  two  goals  in  addendum  1  (there  may  be  more): 

1.  provide  a  GKSM  (workstation  session  capture  metafile)  to  replace  annex  E  of  GKS; 

2.  provide  more  advanced  static  picture  capture  capabilities  (the  additional  functionality  taken  from 
CGI,  with  some  restrictions); 

The  Metafile  Reference  Model  shows  the  first  to  be  a  distinct  type  of  metafile  from  ISO  8632,  whereas 
the  second  is  really  a  proper  extension  of  ISO  8632.  Accordingly,  it  is  inappropriate  to  treat  the  first  as 
an  addendum  to  ISO  8632:  rather  it  would  best  be  progressed  by  one  of  the  other  methods  mentioned  in 
X3H3/88-78. 

The  US  acknowledges  the  advanced  state  of  addendum  1  and  the  desirability  of  not  incurring  further 
delay  in  progressing  the  GKSM  content  of  addendum  1.  However  if  it  were  concluded  that  the  work 
could  be  restructured  in  a  way  that  is  consistent  with  the  Metafile  Reference  Model,  without  incurring 
further  delay  in  standardizing  the  GKSM  content  of  addendum  1,  the  US  would  support  such  a  change. 
We  believe  it  is  within  the  authority  of  SC24,  for  example,  to  convert  the  work  in  progress  from  an 
addendum  to  CGM  to  an  addendum  for  a  normative  annex  to  GKS,  without  causing  a  setback  to  the 
desired  schedule. 
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m.  Consideration  of  Addendum  2 

Please  see  document  X3H3/88-78,  Comments  on  SC24  N23;  Working  Draft  for  ISO  8632  3D 

Addendum  (CGM  Addendum  2)“. 


rV.  Consideration  of  Proposed  Addendum  S 

The  proposed  addendum  3  is  intended  to  be  a  metafile  that  is  of  type  static  picture  capture  (like  CGM] 
with  extended  functional  capabilities  defined  for  use  by  both  both  standard  and  non-standard  client  sys¬ 
tems.  Thus,  this  work  would  correctly  be  undertaken  and  progressed  as  an  addendum  to  ISO  8632.  The 
US  supports  progressing  this  work  as  an  addendum  to  CGM  (ISO  8632). 


V.  Conclusion 

The  U.S.  believes  it  to  be  desirable  to  restructure  the  work  in  progress,  such  that  only  that  functionality 
which  is  consistent  with  the  original  scope,  goals,  and  architecture  of  IS  8632  be  progressed  as  addenda 
to  that  standard.  Work  which  results  in  a  different  type  of  metafile  should  be  progressed  as  a  separate 
standard,  or  as  a  normative  annex  to  the  functional  standard  to  which  the  metafile  relates  (e.g.  GKS, 
GKS-3D,  PfflGS). 

However,  much  benefit  can  be  realized  by  utilizing  the  encoding  techniques,  and  as  far  as  possible  the 
exact  element  encodings,  already  standardized  in  IS  8632  parts  2  through  4.  This  will  serve  to  harmon¬ 
ize  the  different  metafiles,  without  requiring  them  all  to  be  formulated  as  addenda  to  IS  3632. 
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X3H3/88-78 


U.S.  CommcBts  oa  SC24  N23: 
Working  Draft  for  ISO  8632  3D  Addoadum 
(CGM  Addcaduai  2) 


L  Introduction 

The  US  has  two  fundamental  concerns  with  SC24  N23,  the  proposed  3D  addendum  to 
CGM: 

1.  the  scope  and  goals  of  the  addendum  are  unclear,  and  apparently  contrary  to 
decisions  taken  at  the  May  1987  SC21/WG2  meeting; 

2.  the  addendum  process  may  not  be  the  appropriate  method  for  realizing  the  metafile 
requirements  of  constituencies  identified  for  addendum  2  (as  well  as  addendum  1). 

As  part  of  its  review  of  both  addendum  2  and  addendum  1,  the  US  has  derived  a 
reference  model  for  metafiles  (see  document  X3H3/88>77).  We  believe  that  this  model 
clearly  illustrates  the  problems  with  CGM  addendum  2  (as  well  as  the  other  proposed 
addenda).  We  have  included  a  description  of  that  model  with  these  comments,  and  we 
comment  on  addendum  2  in  the  context  of  the  model 


IL  Addendum  2  Comments:  Issues  of  Scope  and  Purpose 

The  attached  Metafile  Reference  Model  (MRM)  shows  that  there  are  two  fundamental 
types  of  metafiles  (session  capture  and  static  state  capture)  and  many  places  in  a  typical 
graphics  architecture  that  a  metafile  may  be  captured;  therefore,  there  are  many  useful 
metafiles.  In  the  .MRM,  the  CGM  (ISO  8632)  is  a  static  state  capture  metafile  at  the 
virtual  device  level  -  it  is  a  picture  capture  metafile. 

In  Valbonne,  it  was  decided  that  the  scope  of  the  CGM  addendum  2  is  to  provide  a 
replacement  for  the  (non-normative)  annex  E  of  GK.S>3D.  The  exact  scope  and  purpose 
of  addendum  2,  as  presented  in  N23,  are  unclear.  We  identify  at  least  3  metafiles  in  the 
MRM  that  addendum  2  purports  to  support 

!.  GKSM-3D 

1  PHIGS  Archive  File 

3.  PHIGS  Metafile  for  Workstation  MO 

The  latter  two  metafiles  have  not  been  previously  identified  as  part  of  the  scope  of 
addendum  2,  nor  have  the  requirements  for  them  been  carefully  studied  by  the  metafile 
working  group.  Furthermore  work  on  the  PHIGS  archive  is  already  in  progress  within 
ISO  and  has  now  reached  the  DIS  stage. 
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The  US  believes  that  addendum  2  should  be  analyzed,  restructured  and  redefined  in  the 
context  of  the  MRM.  A  set  of  target  metafiles  should  be  identified  and  the  scope  of 
each  metafile  clearly  defined  Work  overlapping  other  active  ISO  projects  should  be 
discontinued  or  consolidated  with  the  other  work. 


UL  Addendum  2  Comments  Issuee  of  Organization  of  Work 

The  US  believes  that  it  is  inappropriate  to  use  an  addendum  to  CCM  to  progress 
standardization  of  3D  metafiles,  since  none  of  the  three  types  of  files  (listed  above) 
which  could  be  specified  by  this  addendum  is  at  the  same  level  (Virtual  Device)  and  of 
the  same  type  (static  picture  capnire)  as  the  CGM  (ISO  S632).  To  standardize  metafiles 
that  are  not  properly  extensions  of  ISO  8632  we  recommend  one  of  three  methods: 

1.  as  a  pan  of  or  addendum  to  another  standard,  which  they  are  designed  to  serve; 

1  as  a  distinct  independent  star  jard; 

3.  as  a  new  pan  of  an  existing  metafile  standard. 

ISO  metafile  experts  should  play  a  major  role  under  any  of  the  options,  and  already 
developed  element  sets  and  encoding  techniques  should  be  reused  to  the  maximum  extent 
possible. 
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APPENDIX  9 

TUCSON  METAFILE  REPORT 
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Delegation  Report 

WG3  Metafile  Rapporteur  Group  at  the  Tu'tson 
Meeting  otlSO/JEC  JTC1/TC97/SC24,  June  1988 

Lofinn  ffenatnan.  Head  of  Sub-deiegation 


1.  Overview 

la  early  1988  CGM  Addendum  1  wre  circulated  for  PDAD  ballot,  and  CGM  Addendum  2  Working  Draft 
was  circulated  for  comment.  In  April  SC24  had  a  Special  Working  Group  (SWG)  meeting  which  recom* 
mended  revision  and  improvement  of  the  way  of  progressing  graphics  standards,  and  urged  reference 
model  and  user  requirements  work  precede  new  projects. 

The  Tucson  meeting  was  an  editing  meeting  for  the  Metafile  Rapporteur  Group  of  WG3.  The  main 
tasks  were  to  advance  the  status  of  CGM  Addendum  1  and  Addendum  2.  For  Addendum  1,  the  results 
of  the  PDAD  ballot  were  pre-processed  at  Blakeney,  Emgland  in  April  and  the  goal  of  this  meeting  was 
to  complete  that  processing  and  prepare  the  DAD  text.  For  .\ddendum  2,  the  goal  was  to  process  the 
comments  on  the  Working  Draft  and  prepare  PDAD  text. 

At  the  Fairfax  meeting  of  X3H3,  a  Metafile  Reference  Model  was  derived  and  submitted  as  input  to  the 
Tucson  meeting.  The  impetus  for  this  work  came  from  both  the  recommendations  of  the  SWG  and 
internal  dissatisfaction  within  X3H3  over  the  way  the  addendum  process  was  being  used  for  CGM. 

U.S.  positions  were  generated  recommending  splitting  Addendum  1  into  a  static  picture  capture  portion 
and  a  GKS  audit'  trail  portion.  The  first  would  continue  as  an  addendum  to  ISO  3632  CGM.  and  the 
second  as  a  normative  annex  to  GKS.  For  Addendum  2  it  was  proposed  that  3D  metafiles  not  be  pro¬ 
gressed  as  addenda  to  ISO  3632  but  as  parts  or  annexes  of  their  respective  3D  standards. 

There* was  substantial  agreement  with  these  positions  at  Tucson.  A  number  of  other  national  bodies 
had  simultaneously  arrived  at  similar  positions.  Consequently,  the  CGM  addenda  are  being  split,  res> 
tructured,  and  progressed  substantially  along  the  lines  recommended  in  the  U.S.  position  papers 
(X3H3/88-r7,  78,  79). 


2.  Meeting  Schedule 

—  28  June,  Metafile  Rapporteur  Group  convenes. 

—  1  July,  Metafile  Rapporteur  Group  adjoumes. 

—  2  July,  liaison  meeting  with  SClS  (no  R.G.  activity). 

—  3-6  July,  drafting  and  document  markup.* 

—  3  July,  liaison  meeting  with  CGI. 

—  7  July,  WG3  plenary. 

—  3-9  July,  3C24  plenary. 

*  .Also  took  place  during  R.G.  meeting,  and  during  plenaries. 


3.  Attendance 
Attendance  included: 

US:  Lofton  Henderson,  .Andrea  Frankel,  Barbara  Lurvey,  Peter  Bono; 

—  UK:  Anne  Munrdbrd  (Addendum  1  document  editor),  .Alan  Francis; 

—  France:  Bernard  Troucherie; 

—  Germany:  Eckhard  Moeller  (rapporteur),  Peter  Egloff; 

—  .Austria:  Emaneui  Wenger 

—  Denmark:  Kurt  Alstrup; 
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—  Japan:  Ichiron  Niahioka 


4.  Adminiatrativa  No««a 

Eckhard  Moeller,  the  rapporteur  of  the  Metafile  Elapporteur  Group  within  WG3,  will  not  be  continuing 
due  to  a  change  of  job  reeponaibility.  He  will  continue  through  the  next  R.G.  meeting,  which  will  be  an 
editing  meeting  to  process  the  results  of  the  next  ballots  on  Addendum  1  and  Addendum  2.  in  June^Juiy 
1989. 

The  CGM  \Iaintenanee  Rapporteur  Group  had  been  allowed  to  lapse,  due  to  an  oversight.  There  is  a 
growing  list  of  corrections  to  be  made  to  CGM.  Alan  Francis  was  reappointed  as  rapporteur  for  the 
Metafile  Maintenance  Rapporteur.  .\t  one  time  there  was  a  Metafile  Maintenance  R.G.,  but  it  lapsed. 
At  that  time  Andrea  Frankel  and  Lofton  Henderson  were  the  R.G.  members  for  the  U.S.  It  is  not  clear 
what  if  anything  need  be  done  to  reestablish  membership  in  the  group. 


5.  Technical  Action  List  for  the  Masting 

The  following  comprised  the  major  technical  activities  of  the  meeting. 

1.  Discuss  US  Metafile  Reference  Model  (MRM),  similar  UK  positions,  and  other  national  positions; 
split  and  restructure  both  CGM  addenda  accordingly,  into  two  CGM  addenda  and  annexes  to 
GKS(3D). 

2.  .Addendum  1  technical  issues  resolution  from  PDAD  ballot  and  disposition  of  comments. 

3.  Drafting  and  document  markup  to  effect  the  splitting  of  Addendum  1  and  Addendum  2  (both.still  in 
progress). 

4.  Liaison  with  GKS  R.G.  on  GKS  requirements  for  metafiles,  as  well  as  on  progressing  of  GKSM  con* 
tent  of  Addendum  1  as  a  normative  axmex  of  GKS. 

5.  Liaison  with  VTR  on  conformance  topics  of  extended  CGM  and  GKSM,  as  well  as  registration 
topics. 

6.  Resolutions,  including  position  on  "addendum  3",  etc. 

7.  CGI  liaison  on  areas  of  overlapping  functionality. 

3.  Liaison  with  SC13  (not  an  R.G.  activity  per  se). 

9.  Schedule  and  Future  Work 

These  list  items  are  dealt  with  in  the  following  sub-sections. 

5.1  Referenea  Models  end  Structure  of  Work 

5.1.1  The  .After  introductory  remarks,  introduction  of  delegates,  discussion  and  adjustment  of 

the  agenda,  the  U.S.  presented  Metafile  Reference  Model  (MR\I)  which  was  developed  at  Fairfax 
(X3H3/88-77).  The  MRM  recognized  that  there  are,  in  a  typical  graphics  architecture,  very  many 
different  types  of  metafile  that  could  be  defined  and  standardized.  These  be  divided  roughly  into  two 
classes:  static  (state  capture)  and  dynamic  (session  or  interface  capture).  Within  each  class  there  can  he 
metafiles  defined  at  many  different  levels. 

.According  to  this  model,  the  CGM  (ISO  3632)  is  designated  as  a  static  picture  capture  metafile  at 
roughly  the  Virtual  Device  level.  The  two  ISO  addenda  throw  many  features  into  CGM  which  confuse 
both  its  static/dynamic  nature  and  the  level  at  which  it  e.xists  in  the  graphics  architecture.  The  U.S. 
model  and  associated  positions  recommend  clearly  identifying  the  goal  metafiles  (based  on  user  require* 
ments),  splitting  the  work  in  progress,  and  progressing  the  work  as  addenda  to  CGM  (for  static  picture 
metafiles)  or  additions  to  other  standards  (for  dynamic  metafiles,  e.g.,  GKS\1,  ..). 

5.1.2  National  Reapanaes  to  the  .VfRiVf  The  R.G.  discussed  at  length  the  model  and  its  implications  on 
what  metafiles  to  standardize  and  how  to  progress  the  work.  The  R.G.  was  unanimous  in  endorsing  the 
model  and  the  principle  of  splitting  and  restructuring  the  work.  The  U.K.  had  been  dissatisfied  with  the 
CGM  addenda  on  philosophical  grounds,  and  was  particularly  supportive  of  the  principles  of  the  model 
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%ad  the  idea  of  restnicturing. 

S.l.S  Spiittinf  tk*  Work  —  Coneeptuai  There  was  ao  objectioa  to  coociauing  to  progress  che  static  por* 
tion  of  Addendum  1  as  a  CGM  addendum,  to  form  a  "static  structured  picture  capture"  metadle. 

Most  of  the  problems  and  discussion  were  related  to  what  to  do  about  che  GKSM  content  of  Addendum 
1.  From  a  practical  standpoint,  two  categories  of  concerns  were  raised: 

1.  the  restructuring  should  not  slow  down  che  GKS\1  (France); 

2.  is  a  standard  GKSM  (similar  to  annex  E  of  GKS)  needed  at  all;  is  there  a  more  useful  dynamic 
metadle  (UK.,  Germany,  Austria). 

The  U3.  proposed  making  che  GKSM  a  normatire  annex  to  GKS,  to  replace  the  current  annex  E.  To 
avoid  delay,  we  recommended  doing  this  under  the  authority  of  the  Egham  resolutions,  as  a  simple 
conversion  of  that  mandated  work  from  a  CGM  addendum  to  a  GKS  addendum.  We  further  recom* 
mended  that  a  New  Work  Item  (NWI)  was  not  reqtiired,  and  that  the  work  should  be  progressed  at  the 
same  pace  as  Addendum  1  and  be  done  by  the  metadle  experts  in  the  Metadle  R.G. 

Although  there  was  general  agreement  that  GKSM  belonged  in  GKS,  there  was  significant  debate  on 
where  and  how.  There  was  significant  disagreement  from  the  UK.  on  the  proposition  that  the  GKSM 
could  simply  be  attached  to  GKS  —  within  the  UK.  delegation  (though  not  necessarily  the  R.G. 
members)  there  was  che  belief  that  SC24  would  not  allow  the  GKS  annex  without  a  NWI. 

Further  confusion  arose  concerning  due  to  the  uncertain  scope  and  timetable  of  GKS  revision.  Would  it 
be  a  fast  minimal  maintenance  effort  to  fix  problems  in  GKS  357  Or  would  it  be  a  more  general  revision 
to  produce  che  new  API,  GKS  9x7  Should  GKSM  be  an  ammendment  to  GKS  35  or  should  it  track 
what  was  happening  in  maintenance  and  revision  to  the  .API?  The  Metafile  R.G.  consensus  was  that 
the  fastest  possible  GKSM  addition  to  GKS  35  was  the  only  realistic  way  that  progress  could  be  made. 

The  biggest  issue,  however,  was  not  how  to  progress  GKSM  but  whether  a  standard  GKSM  audit 
metafile  was  needed  at  all.  The  UK.  and  Austria,  and  to  some  extent  Germany,  maintained  that  a 
standard  GKSM  was  not  needed.  Germany  proposed,  and  there  was  agreement  from  some  of  che  ocher 
delegates,  that  a  "dynamic  picture  capture"  metafile  was  much  more  useful  than  the  pure  GKSM  audit 
trail.  The  dynamic  picture  metafile  would  allow  multiple  pictures,  as  opposed  to  the  single  picture  of 
GKSM.  All  GKS  control  functions  that  explicitly  commanded  clearing  or  regeneration  (CLEAR. 
update,  REDRAW  .ALL  SEGMENTS,  ..)  would  be  mapped  to  new  pictures  and  would  not  be  written 
to  the  metafile.  Those  ftmctions  with  potentially  dynamic  effects  (representation  functions,  workstation 
transformation,  segment  attributes  and  manipulation,  ..)  would  be  written  to  the  metafile. 

There  was  further  discussion  and  yet  more  options  on  this  topic  were  introduced  during  the  WGl  GKS 

R. G.  liaison  meeting  —  see  below. 

The  resolution  (by  meeting’s  end)  was  that  we  would  progress  the  static  structured  metafile  and  the 
Eghaffl!>mandaced  GKSM  audit  trail.  Dynamic  picture  metafiles  could  be  undertaken  later  after  the 
requirement  is  studied  and  demonstrated.  (The  extensibility  is  built  into  the  ammended  CGM  to  make  it 
relatively  easy). 

S. 1.4.  Pirtieviar  Teehnieai  [anet  Arising  from  the  Split  Splitting  the  addenda  reopened  some  issues. 
The  split  of  the  static  and  dynamic  portions  of  .Addendum  L  and  the  progression  of  the  GKSM  audit 
metafile  as  a  part  of  GKS  led  to  some  technical  issues  and  resolutions. 

1.  Issue:  What  should  be  done  with  Color  Table  and  Pattern  Table,  which  are  potentially  dynamic 
and  are  allowed  in  the  picture  body  in  CGM? 

Resolution;  It  was  acknowledged  that  CGM  IS  3652  was  itself  somewhat  "impure"  in  regard  to 
being  static.  Color  Table  and  Pattern  Table  are  allowed  in  the  picture  body.  (The  standard  says 
that  the  effect  of  changing  an  index  with  pnmitive  bound  to  it  is  not  standardized.)  CGM  .Add.l 
will  still  allow  the  elements  in  the  picture  body,  but  will  also  allow  them  in  the  Picture  Descriptor. 
Use  in  the  picture  body  will  be  discouraged. 

2.  Issue:  Should  there  be  segments  the  static  picture  metafile  at  all?  If  the  static  picture  metafile  is 
at  the  level  of  the  virtual  device,  and  if  it  is  static,  then  the  MRM  might  imply  that  segments 
should  not  be  in  the  metafile. 


Resolutioa:  Segments  can  be  considered  as  a  shorthand,  for  data  compression,  at  this  level  of  the 
MRM,  Furthermore,  they  even  exist  in  GKS  at  this  level  (the  device  level),  as  WDSS.  Segments  are 
useful  and  are  not  meousistent  with  ttie  MRM.  However  they  must  be  static  segments  —  the  gram* 
mar  of  static  metafiles  will  not  allow  segment  control  functions  such  as  DELETE,  and  will  not 
allow  segment  attribute  functions  to  be  used  in  a  way  that  would  imply  picture  dynamics.  In  static 
metafiles  segment  attributes  are  only  allowed  within  segments,  at  the  beginning,  before  any  primi¬ 
tives.  The  CGI  segment  control  functions  that  are  eliminated  from  CGM  .A.dd.1  are  DELETE  SEG¬ 
MENT,  DELETE  ALL  SEGMENTS,  RENAME  SEGMENT.  REOPEN  SEGMENT,  REDRAW  SEG¬ 
MENT,  REDRAW  all  SEGMENTS. 

A  peripheral  issue  is  whether  only  global  segments  should  be  allowed.  There  were  arguments  that 
this  was  the  only  consistent  way  (according  to  the  MRM)  to  allow  segments  in  the  static  picture 
metafile.  It  was  decided  is  that  local  segments  caused  no  problem,  as  long  as  dynamic  effects  were 
proscribed  by  the  grammar  as  described  above. 

3.  Issue:  Many  elements  in  .Addendum  1  were  taken  from  functions  of  CGI  —  segment  control  and 
attribute,  bundle  representation,  workstation  transformation,  primitive  attributes,  etc.  Is  it 
appropriate  that  GK2M  still  be  expressed  in  terms  of  these  elements  and  the  existing  elements  of 
CGM  if  GKSM  is  to  be  a  GKS  annex? 

Resolution:  if  the  elements  were  still  to  be  a  part  of  static  CGM,  such  as  separate  TEXT  FONT 
INDEX  and  TEXT  PRECISION  elements,  then  they  would  be  used  in  GKSM;  if  the  elements  would 
no  longer  exist  in  static  CGM  —  the  PREPARE  VIEW  SLllFACE,  MAKE  PICTURE  CURRENT,  .. 
from  which  the  GKSM  CLElAR,  REDRAW  SEGMENTS,  ..  had  been  built  —  then  they  would  be 
eliminated  also  Grom  GKSM  and  the  GKS  functions  CLEIAR,  UPDATE,  REDRAW,  ..  would  be 
encoded  as  GKSM  elements. 

The  basic  principle  is  to  maintain  as  much  overlap  as  possible  in  metafile  specifications,  and  only 
invent  and  add  new  elements  where  such  were  needed.  Such  are  needed  in  cases  where  semantics 
differ  significantly,  or  an  awkward  mapping  is  required  to  define  a  function. 

Based  on  the  principles  enumerated  above,  some  of  the  Issues  about  whether  GKSM  needs  different 
elements  and  encodings  for  some  specific  functions  are  still  being  sorted  out. 

4.  Issue:  What  do  category  and  element  set  mean  and  what  values  should  be  standardized? 

Resolution:  Better  definition  of  .METAFILE  CATEGORY  and  MET.AFILE  ELEMENT  SET  short¬ 
hands  was  begun  at  Blakeney  and  continued  in  Tucson  subsequent  to  the  restructuring  of  the 
addenda.  Category  now  refers  purely  to  grammar  of  the  metafile,  although  a  maximum  element  set 
is  implied  in  some  cases.  The  following  categories  are  currently  defined  (these  are  probably  not  the 
final  names): 

•  basie_static  —  the  current  CGM; 

•  struetured_static  —  the  grammar  of  the  structured  static  CGM; 

•  gksm_audit  —  the  dynamic  GKSM  audit  trail  metafile; 

•  3d  equivalents  of  the  last  two  (more  about  3d  later). 

The  following  element  set  shorthands  will  be  defined; 

•  drawing  and  drawing_plus_control  —  the  shorthands  of  the  current  CGM. 

•  structured_static_all  —  all  elements  in  the  structured  static  CGM. 

•  gksnutatic^all  — -  those  elements  that  would  exist  in  a  GK3\1  static  picture  capture;  speciai 
geometric  pnmitives  like  circles  and  arcs  are  not  included  (see  next); 

•  extended^primitivesjet  —  ail  those  primitives  in  CGM  plus  .Addendum  1  which  are  beyond  the 
basic  primitive  set  of  GKS. 

•  gksm_audit_all  —  those  elements  (less  the  extended  primitives)  that  would  be  used  in  a  GKSM 
audit  trail  metafile. 

•  3d  equivalents  of  all  of  the  above. 

The  intention  in  splitting  the  special  primitives  out  from  the  GKS  element  sets  was  to  give  imple¬ 
mentations  a  convenient  way  to  express  both  the  case  where  GKS  GDP  maps  to  metafile  GDP  and 
the  case  where  it  maps  to  the  CGM  extended  primitives. 
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5.  Issue:  wixAt  should  happen  to  CGI  pick  related  functions  in  the  static  mscafile? 

Resolution:  pick  id  and  se^ent  pick  priority  stay  in;  they  are  considered  to  be  primitive  attributes 
and  segment  attributes  that  record  useful  information  in  a  snapshot.  Segment  detectability  is  elim¬ 
inated. 

6.  Issue:  Should  Pixel  .\rray  and  Drawing  Mode  remain  in? 

Resolution:  There  were  arguments  that  this  was  below  the  static  picture  level  in  the  MR\I.  There 
was  further  concern  over  its  (in)atability  in  CGI  (it  has  been  made  a  raster  fimction.  not  treated  in 
the  pipeline  as  are  geometric  primitives).  Counter  arguments  were  that  a  metafile  a  one  level  could 
consistently  incorporate  functionality  from  a  tower  level  (comparison  to  OSI  was  used  to  support 
this  position).  And  the  CGM  grammar  could  take  care  of  excluding  it  from  segments  and  otherwise 
being  treated  as  a  geometric  primitive.  Pixel  Array  was  retained  in  .Addendum  I.  Drawing  Mode 
was  similarly  retained,  but  without  the  new  values  added  by  CGI  at  this  meeting. 

5.2  Addendum  1  PDAD  Teehnieal  Issues  Resolutton 

One  of  the  output  documents  of  the  Tucson  meeting  (not  yet  received)  will  be  a  disposition  of  comments 
on  the  .Addendum  1  PDAD  ballot. 

Much  of  the  technical  issue  resolution  done  at  Blakeney  became  moot  after  the  splitting  of  CGM  .Add.l 
and  GKS  Add.l.  For  example,  many  of  the  CGI  control  functions  were  removed,  so  issues  related  to 
those  disappeared.  Significant  Blakeney  results  that  remained  intact  include: 

1.  The  METAFILE  CATEGORY  and  METAFILE  EL£\IENT  SET  elements  are  made  orthogonal  as 
much  as  possible  —  category  refers  on  to  grammar  (but  may  imply  a  maximum  element  set). 

2.  MODIFY  FONT  LIST  and  MODIFY  CHARACTER  SET  LIST  elements  are  removed. 

3.  The  grammar  for  Addendum  1  will  show  a  necessary  order  for  some  of  the  Metafile  Descriptor  ele¬ 
ments  (Version,  Element  Set,  Category,  Description),  as  per  a  U.S.  comment. 

■4.  The  GKSMO  element  set  has  been  removed. 

In  addition,  numerous  changes  were  agreed  to  make  the  CGM  elements  match  corresponding  CGI  func¬ 
tions.  The  description  is  being  modified  throughout  to  be  more  appropriate  for  a  metafile  specification 
—  much  of  it  was  borrowed  from  functional  standards  (e.g.,  CGI)  and  had  not  been  adapted  to  CGM. 

5.3  Drafting  to  Split  the  Addenda 

A  significant  amount  of  drafting  for  the  CGM  Add.l  was  accomplished  at  Tucson.  Much  (most)  of  the 
drafting  for  GKSM  remauis  to  be  done.  .A  number  of  particular  technical  problems  are  being  sorted  out 
according  to  the  principles  we  derived  for  how  to  accomplish  the  split. 

5.4  Liaison  with  GKS 

On  the  afternoon  of  30  June  there  was  a  liaison  meeting  with  the  GKS  maintenance  group.  CGM  was 
seeking  some  guidance  as  to  what  types  of  metafiles  were  perceived  as  needed  for  GKS  ( refer  above,  to 
the  doubts  over  whether  a  standard  audit  trail  GKSM  is  needed).  CGM  also  wanted  guidance  on  pro¬ 
cedural  issues  for  attaching  a  GKSM  aiuex  to  GKS.  McConnell  added  to  the  agenda  the  topics  of  stan¬ 
dard  items  types  for  GKS,  and  putting  the  additional  primitives  of  the  metafile  into  the  GKS  .API. 

Considerable  time  at  the  meeting  was  spent  reviewing  the  current  status  and  plans  of  metafile  addenda. 
.A  new  type  of  metafile  of  Interest  to  some  GKS  constituents  was  proposed  —  an  audit  trail  of  the  .API. 

Finally,  there  was  consensus  on  two  points: 

—  The  .Metafile  R.G.  should  complete  work  on  an  audit  trail  GKSM.  to  be  attached  to  GKS  35  as  a 
normative  annex  (unanimous); 

—  The  GKS  Maintenance  R.G.  and  the  Metafile  R.G.  should  continue  to  liaise  to  determine  what 
other  sorts  of  metafiles  need  be  standardised  for  GKS. 
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S.5  Llaiaoa  with  VTR 

On  1  July  then  wsa  a  liaiaon  tneetiaj  between  Metafiles  and  VTR.  Topics  included: 

—  Coafonnaace  testing  and  formal  grammars; 

—  The  role  of  Application  Profiles  (APs); 

—  Current  status  of  conformance  testing  for  CGM: 

—  Registration  procedures. 

On  the  first  point,  it  was  agreed  th^.t  conformance  testing  could  be  greatly  enhanced  if  the  formal  gram¬ 
mars  of  the  metafile  standards  were  normative.  (The  formal  grammars  of  the  CGM  addenda  will  be). 
It  is  generally  agreed  that  APs  provide  the  basis  for  testing  generators  and  interpreters.  In  CGM  Add.l 
there  will  still  be  no  specification  of  generator  and  interpreter  behavior  (although  the  formal  grammar 
does  give  something  to  test  the  generator  on).  There  is  work  going  on  in  ISO  on  standardizing  .APs. 
This,  it  was  generally  agreed,  would  help  conformance  testing  and  would  be  .a  good  idea.  Pink  and 
Mumford  will  look  into  this  further. 

There  was  a  report  on  CGM  testing  work  being  done  by  GMD.  .A  set  of  test  metafiles  is  being 
developed,  based  on  GKS.  These  are  simple  metafiles  with  just  a  single  primitive  or  two.  There  is  also 
work  on  a  syntax  analyzer,  to  check  generator  output.  It  is  felt  that  it  will  be  1/2  to  1  year  before  the 
testing  tools  are  ready  (it  is  unclear  what  "ready"  means  here). 

The  Registration  Procedures,  TR  9973,  are  finished.  The  final  draft  is  being  sent  to  the  secretariat  this 
week.  The  proposals  for  additional  linetypes  and  hatch  styles,  for  engineering  drawing  support,  have 
been  mailed.  Skall  wants  a  90  day  ballot  on  these. 

S.g  Liaison  with  CGI 

Barbara  Lurvey  (WG3  Head  of  Delegation)  met  with  and  worked  with  the  Metafile  R.G.  for  its  entire 
official  4-day  meeting.  Her  efforts  were  invaluable  in  bringing  CGI  positions  and  issues  into  CGM.  and 
taking  CGM  concerns  back  to  CGL  It  was  hoped  that  topics  of  interest  to  CGM  could  be  dealt  with  at 
the  very  beginning  of  the  CGI  meeting,  with  CGM  experts  present.  The  very  heavy  workload  of  CGI 
forced  the  liaison  meeting  to  the  end. 

The  major  concern  within  CGM  was  over  stability  of  those  CGI  functions  which  had  been  incorporated 
into  Addendum  I.  There  was  particular  concern  over  Pixel  .Array  and  Drawing  Mode,  and  the  appear¬ 
ance  of  the  new  clipping  mode  functions.  CGM  intends  to  go  to  DAD  ballot  with  .Addendum  1.  whereas 
CGI  is  going  to  2ad  DP.  This  creates  a  certain  awkwardness  since  CGM  is  following  CGI  on  the  func¬ 
tionality  and  encoding  of  the  set  of  functions  in  question.  CGM  desired  a  resolution  that  would  del¬ 
ineate  the  area  of  overlap  between  the  two  standards  and  "freeze"  that  set  in  both  standards  (except  for 
the  fixing  of  serious  errors). 

CGI  endorsed  progressing  CGM  .Add.l  to  DAD,  with  inclusions  of  those  CGI  functions  that  still  made 
sense  in  a  static  structured  metafile.  CGI  recommended  that  Pixel  .Array  and  Drawing  Mode  be 
removed  (see  the  discussion  above).  It  was  not  until  the  WG3  plenary  that  it  was  resolved  to  leave 
them  in. 

The  next  editing  meetings  of  CGM  and  CGI  will  be  held  in  parallel.  June  1989.  CGM  will  be  processing 
the  results  of  the  DAD  ballots  on  CGM  .Add.l  and  GKS  .Add.l  and  the  PD.AD  ballots  on  CGM  .Add. 2 
and  GKS  .Add.2.  CGI  'vill  be  processing  the  2nd  OP  ballot  on  CGI. 

S.T  Liaison  with  SC18 

On  2ad  July  there  was  a  liaison  meeting  between  SC24  and  SClS.  lasting  from  9:00  to  -l.JO.  .Although 
this  was  SC24  liaison,  not  juost  CGM  or  WG3  liaucn,  some  of  the  results  are  important  for  the  future 
work  on  metafiles  within  SC24/WG3.  Other  reports  from  Tucson  wiil  present  the  results  of  this  meeting 
more  comprehensively. 

Both  SCs  presented  their  structure  and  program  of  work,  highlighting  significant  work  in  progress  and 
work  planned.  SC24  gave  a  presentation  on  SPDL,  on  the  ISO  3613  (ODA/ODIF)  Color  .Addendum,  on 
ISO  9541  (Font  Architecture).  From  the  standpoint  of  CGM  and  extended  CGM.  the  most  important 
result  was  the  beginning  of  a  dialog  on  how  to  incorporate  the  Font  and  Color  work  of  SClS  into  SC24 
standards.  Conversely,  it  appears  that  some  SC24  work  (e.g.,  CGI  datastreams.  raster,  and  other  areas) 
may  be  of  value  to  SClS  projects  in  progress.  Refer  to  other  Tucson  reports  for  details  of  the  meeting 
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aad  reaoiutiooa. 


9.  About  Addendum  3 

Tbe  Metafile  R.G.  did  aoe  dead  with  "Addendum  3",  CGM  extensiona  for  cechnical  drawing,  pubiiahiof, 
and  graphic  art  quality  pictures.  Ac  BlaJceney  the  position  was  taken  that  the  work  is  important  and 
should  be  progressed,  possibly  by  a  group  comprised  of  experts  from  metafiles.  CGI.  .APIs,  etc. 

WGl  recommended  establishment  of  a  number  of  study  groups,  some  on  specific  technical  topics  (pro* 
duct  data  geometry,  text,  etc)  and  some  on  particular  new  standards  efibrts  —  see  the  WGl  report  for 
comprehensive  discussion.  One  of  the  study  groups  is  for  "CGM  extensions  for  enhanced  static  picture 
capture"  —  "addendum  3".  Lofton  Henderson  is  the  rapporteur.  There  will  be  at  least  two  meetings  in 
the  next  year,  scheduled  in  conjunction  with  the  technology  groups’  meetings.  The  first  is  tentatively 
scheduled  for  Germany,  December,  meeting  in  conjuction  with  geometric  and  text  groups. 

The  U.S.  should  prepare  positions  on  both  scope  it  goals  and  technical  content  for  this  initial  meeting. 


r.  Status  and  Schedules 

Both  CGM  Add.l  and  GKSM  (GKS  .\dd.l)  will  be  forwarded  for  DAD  ballot.  Both  CGM  .A.dd.2  and 
GKSM-3D  (GKS  Add.2)  will  be  forwarded  for  PDAD  ballot.  The  tentative  schedules  are; 

CGM  Addendum  1  and  GKS  Addendum  1: 

—  Oct  38:  DAD  ballot  commences. 

—  .A.pr  39:  DAD  ballot  closes. 

—  Jun  39:  Editing  meeting. 

—  .A.ug  39;  IS  text  forwarded  to  ISO  Central  Secretariat. 

CGM  .addendum  2  and  GKS  .A.ddendum  2: 


—  Nov  88: 

—  Feb  89: 

—  Jun  89: 

—  .A.ug  39: 

—  Oct  39: 

—  .\pr  90; 

—  Jun  90; 


PDAD  ballot  commences. 

DAD  ballot  closes. 

Editing  meeting. 

DaD  text  produced. 

DAD  ballot  commences. 

DAD  ballot  closes. 

IS  text  forwarded  to  ISO  Central  Secretariat. 
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unj^r  1  j 


ISO/IEC  JTC:/SC24  N18S 


RESOLUTION  1~Appomtment  of  SC24  Convenors 


SC24  approves  the  appointment  of  these  Working  Group  Convenors  for  a  three-year 
term  of  office: 


WG  Number 

WG1 

WG2 

WG3 

WG4 

WG5 


Title 

Architecture 

Application  Programming  Interface 
Metafile  and  Device  Interface 
Language  Bindings 
Validation,  Testing,  and  Registration 


RESOLUTION  2— SC24  Structure  and  Terms  of  Reference 


Convenor 
P.  Bono 
J.  Bettels 
D.  Arnold 
B,  Shepherd 
B.  Kirsch 


SC24  approves  the  working  group  structure  and  terms  of  reference  in  document  SC24 
N213. 


RESOLUTION  3 — SC24  Procedures  for  Preparing  NWI  Proposals 

SC24  instructs  its  Secretariat  to  forward  SC24  N171  for  3  month  letter  ballot.  The 
comments  will  be  resolved  by  the  Requirements  RG  at  the  WG1  meeting  in  March  1989, 
WGl  will  report  to  the  SC24  Charman  whether  the  comments  have  been  satisfactorily 
resolved  and  will  recommend  to  the  Chairman  whether  the  document  (as  revised) 
should  be  accepted  by  the  Charman  on  behalf  of  SC24  or  circulated  for  another  ballot 

RESOLUTION  4— Implementation  of  Requirements  Procedures 

SC24  requests  its  National  Bodies  and  experts  to  assist  its  Working  Group  1  in  the 
irnplememation  and  maintenance  of  the  procedures  as  described  in  Document  SC24 
N1 71  as  revised  by  the  results  of  the  baiotting  period  described  in  Resolution  3. 

National  Bodies  and  experts  are  encouraged  to  cooperate  in  this  endeavour  and  in 
finding  sponsors  for  computer-aided  assistance  of  this  process. 

RESOLUTION  5— Establishment  of  SC24  Advisory  Group  (AG) 

SC24  establishes  an  Advisory  Group  which  consists  of  one  delegate  appointed  by  each 
P-memberis  National  body.  SC24  Working  Group  Convenors,  SC24  Chairman  and 
Secretariat.  The  SC24  Chairman  presides  as  Chair  of  the  Advisory  Group. 


e 
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lSa/1ECJTC1/SC24  RESOLUTIONS 


DRAFTS 


ISO/1EC  JTd;SC24  Nisa 


RESOLUTION  6 — SC24  Advisory  Group  -  Area  of  Work 

The  SC24  Advisory  Group  provides  advisory  and  management  suopcrt  for  the  SC24 
Chairman  and  Secretariat  The  AG  is  also  concerned  with  coordination  of  liaisons  with 
Organizations  outside  SC24  (e.g.  SC2,  SCI 3.  SC21,  SC22.  TC134.  TC10)  on  all  topics 
of  concern  to  SC24.  The  AG  helps  formulate  the  Strategic  Plan  for  SC24  and  gives 
procedural  guidance  to  Working  Groups. 


RESOLUTION  7 — SC24  Advisory  Group— Terms  of  Reference 

SC24  AG  should  operate  consistently  with  SC24  procedures  and  resolutions  and  shall 
report  in  writing  to  SC24  Plenary  Meetings. 


RESOLUTION  8 — SC24  Advisory  Group— National  Point  of  Contact 

SC24  requests  its  National  Bodies  to  nominate  a  national  point  of  contact  for  the  SC24 
AG  in  writing  to  the  SC24  Secretariat  by  1983-10-01.  This  will  facilitate  direct  contact 
with  the  AG  participants  and  aid  continuity  in  AG  membership. 
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ISO/IEC  JTd/SC24  RESOLUTIONS 


DRAFT  3 


ISO/IEC  JTCiySC24  N1 88 


RESOLUTION  9— Approval  of  Study  Periods 

SC24  approves  the  commencement  of  study  periods  to  provide  the  basis  for  developing 
a  consistent  set  of  NWIs  for  the  following  new  areas  of  work: 

New  APIs  (resulting  from  the  technical  work  of  the  GKS  Review  RG) 
containing  functionality  required  in  the  1993  time  frame  aimed  at  producing  at 
least  a  NWI  for  the  GKS  user  community. 

Windowing  Environments 

An  API  for  Imaging 

Extensions  to  the  CGM  Static  Picture  Capture  Capabilities. 

Extensions  to  PHIGS 

Each  study  period  should  consider  at  least  these  items  in  conjunction  with  the  indicated 
Group; 


Requirements 

• 

[WG1 1 

Reference  Model 

(WG1 1 

Encodings 

[WG3] 

Language  Bindings 

[WG4] 

Registration 

[WGS] 

Validation  and  Testing 

[WGS] 
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ISO/IEC  JTa/SC24  RESOLUTIONS 


DRAFT  3 


tSO/lEC  JTC1/SC24  Ml  88 


RESOLUTION  10 — Approval  of  Study  Groups 


SC24  appoints  Special  Rapporteurs  to  study  the  following  topics  according  to  the 
Terms  of  Reference  in  the  indicated  documents: 


Topic 

Improved  Graphical 
Text  Model 

Impact  of  Windowing 
cn  Graphics  Standards 

Improved  Graphical 
Input  Model 

Product  Data  Geometry 
Extensions  to  PHIGS 


Source 

WG1 

WG1 

WG1 

WG1 

WG2 


Terms  of  Reference 
SC24  N172 

SC24  N174 

SC24  N173 

SC24  N175 
SC24  N21 1 


RESOLUTION  11 — SC24  Program  of  Work 

SC24  approves  the  items  of  work,  target  dates,  and  document  editors  in  SC24  N1 37. 
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ISO/IEC JTC1/SC24  RESOLUTIONS  DRAFTS  ISO/lEC JTC1/SC24 N18S 

RESOLUTION  12— Appointment  of  SC24  Rapporteurs 

SC24  approves  these  rapporteurs: 

Rapporteur  Topic 

G.  Grinstein  Requirements 

J.  Poller  Reference  Model  of  Computer  Graphics 

J.  McConnell  GKS-3D 

J.  Bettels  PHIGS 

K.  Vecchiet  CGI 

E.  Moeller’  CGM 

J.  Pink  Validation  and  Testing 

M.  Skail  Registration 

K.  Brodlie  GKS  Maintenance 

J.  Rix  New  APIs  for  Computer  Graphics 

P.  ten  Hagan  Windowing  Environments 

G. S.  Carson  Imaging  API 

L  Henderson  Extensions  to  CGM  for  enhanced  static  picture  capture 

H.  Stenzel  Improved  Graphical  Text  Model 

W.  Hubner  Impact  of  Windowing  on  Graphics  Standards 

R.  van  Liere  Improved  Graphical  Input  Model 

E.  Jungmann  Product  Cata  Geometry 

A.  Francis  Metafile  Maintenance  Raoporteur 

W.  Clifford  Extensions  to  PHIGS 

(ad  hoc) 

E.  Moeller*  CGM  for  GKS  Workstation  audit  trail 
•  temporary 
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!SC/!SC  JTC1/SCS4  RESOLUTIONS 


DRAFT  3 


ISO/lEC  JTC1/SC24  NlSS 


RESOLUTION  13— SC24  External  Liaisons 

SC24  approves  the  following  external  liaison  representatives: 


Name 

G.S.  Carson 

Liaison  to 
SC21 

R.  Fairbaims 

SC21[WG51 

D.  Arnold 

SC21[WG5] 

L  Kctsch 

J.  McConnell 

SC13 

J.  Rix 

TCia4/SC4 

A,  Ducrot 

SC2 

E.  Jungmann 

JTC1  SG-FS 

G.  Schaeffer 

SC22 

M.  Sparks 

SC22 

G.  Cuthbert 

SC22 

1.  Grieger 

SC22 

D.  Larson 

SC22 

Subject 
Open  Systems 

FTAM  document  types  for  COM 

Terminal  Management 

Text  and  Office  Systems 
including  SPDL 

Industrial  Automation  Systems/ 
Standard  for  the  Exchange  of 
Product  Model  Data 

Character  Sets  and  Coding 

Functional  Standardization 

C  Language ' 

Language  Binding  Techniques 
Ada  Language 
FORTRAN  language 
Pascal  Language 


RESOLUTION  13A — Advisory  Group  Meetings 

SC24  approves  the  following  meeting  for  its  AG: 

Date  Place  Topic 

1 989-03  FRG 

(Schcnhut)  [adjacent  to  WGi] 


Category  Purpose 
AG 


ISO/IEC  JTC1/SC24  RESOLUTIONS 
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ISO/IEC  JTC1/SC24  N138 


RESOLUTION  14— Working  Group  1  Ad  Hoc'Rapporteur/EditIng  Meetings 

SC24  approves  the  following  schedule  of  meetings  for  its  VVorking  Group  1  for  the 
period  up  to  the  next  SC24  plenary  meeting; 


Oates 

Place 

Topic 

Category 

Purpose 

88-11 

Boston,  USA 

Imaging  API 

RG 

Evaluate 

(Grinstein) 

Requirements 

RG 

National  Body 
Input  -  set 
drafting  tasks 

88-11 

Copenhagen 

Windowing  Environment 

RG  Evaluate 

Denmark 

(Korn) 

Impact  of  Windowing  SG 

RG 

National  Body 
Input  -  set 
drafting  tasks 

88-12 

FRG 

CGM  Extensions 

RG 

Evaluate 

(Jungmann) 

Improved  Text  SG  RG 

Product  Data  Geometry  SG  RG 

National  Body 
Input  -  set 
drafting  tasks 

89-01 

Paris,  Francs 
(Ducrot) 

Reference  Model 
of  CG 

RG 

Produce  2nd 
Working  Draft 

between 

O') 

•  •  t 

GKS  Maintenance 

RG 

Produce  NWl 

88-12  and 

UK 

VT  &  R  Liaison 

and  base 

89-02 

(Brcdlie) 

(with  WG5> 

document 

??89-02 

Amsterdam, 

New  API 

RG 

Evaluate 

NL 

(ten  Hagen) 

Improved  Input  SG 

RG 

National  Body 
Input  -  set 
drafting  tasks 

??89-03 

FRG 

Requirements 

RG 

Consider 

(Encamagac) 

77 

WG1 

National  Body 
Comment  on 
SC21  N171 
and  revise 

7789-04 

FRG 

(KrPmker) 

Imaging  API 

RG 

Evaluate 
National  Body 
Input  -  set 
drafting  tasks 
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ISO/IEC  JTC1/SC24  N183 


39-05 

CcpenhEgen 

Denmark 

(Korn) 

Requirements 

RG 

Planning  for 
implementation 
of  Nl  71 .  Review 

forms.  Begin 

processing 

requirements. 

??89-04 

USA 

Product  Data  Geometry  SG 

RG 

Agree  output 

Skall 

[Joint  meeting  with  CQM 
extensions] 

Documents 

??a9-06 

Amsterdam, 

Windowing  Environments 

RG 

Agree  output 

Netlterlands 
(ten  Hagen) 

Impact  of  Windowing  SG 

FG 

Dccu.menis 

??89-07 

O'? 

•  •  • 

New  API 

RG 

Examine  new 

UK 

API  in  light  of 

(Cartledge) 

Improved  Input  SG 

RG 

other  study 
groups. 

Agree  output 
Documents 

?789-0a 

F!=.G 

Reference  Model 

RG  * 

Take  2nd  WD 

(Poller) 

GKS  Maintenance 

RG 

comments. 
Revise  base 
documents  in 

89-07 

Boston,  USA 

light  of  NationaJ 
Body  comments 

Requirements 

RG 

Examine  and 

(Grinstein) 

reevaluate 
implementaiicn 
of  N 171.  Review 
and  revise 
forms.  Process 
requirements. 

7789-09 

77, Japan 

Imaging  API 

RG 

Agree  Cutout 

(Kawai) 

Document 
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RESOLUTION  15— Working  Group  2  Ad  Hoc/Rapporteur/Editing  Meetings 

SC24  approves  the  following  schedule  of  meetings  for  its  Working  Group  2  for  the 
period  up  to  the  next  SC24  plenary  meeting: 


Date 

Place 

Topic 

Category 

Purpose 

between 
83*10  and 
38-11 

FRG 

(Rix) 

PHIGS  Extn. 

ad  hoc  RG 

Prepare  init.  draft 

between 
39-01  and 
89-02 

Switzerland 

(Bettels) 

PHIGS  Extn. 

ad  hcc  RG 
and  WG 

Study  SC24  ballot 
results  and  revise 

NWI  proposal  for  JTC1 
letter  ballot 

between 
89-06  and 
89-07 

UK 

(Stapleton) 

PHIGS  Extn. 

RG 

Study  comments  on 

Initial  draft  and 
prepare  POAO 
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ISQ/IEC  JTa/SC24  RESOLUTIONS 


DRAFT  3 


ISO/IEC  JTC1/SC24  N188 


RESOLUTION  16 — Working  Group  3  Ad  Hoc/Rapporteur/Edlting  Meetings 

SC24  approves  the  following  schedule  of  meetings  for  its  Working  Group  3  for  the 
period  up  to  the  next  SC24  plenary  meeting: 


Oates 

Place 

Topic 

Category 

Purpose 

19-23 

Sept. 

1983 

Norfolk,  UK 
(D.  Arnold) 

CGI 

Drafting 

Meeting 

To  implement 
resolutions  of  issues 
from  Valbonne.San 
Diego,  and  Tucson 
CGI  RG  meetings  and 
preparation  of  2nd  DP 
text. 

May 

1989 

Berlin/St.  Augustin 
FRG 

(C.  Egelhaff) 

CGI  Pre- 

Meeting 

[Liaison  with.VTR] 

Preliminary  analysis 
of  comments  on  the 
2nd  DP 

June  /July 
1989 

Hawaii 

USA 

(D.  Larson) 

CGM  Add 

GKS  Audit 
Trail 

Editing 

Meeting 

To  prepare  responses 
to  CGM  DADI  ballot 
and  to  prepare  final 
CGM  ADI  text;  to 
review  comments  on 
CGM  PDAD2  ballot; 
to  preoare  responses 
to  GKS  DADI  ballot 
and  to  prepare  final 
GKS  ADI  text. 

CGI 

Editing 

Meeting 

To  prepare  responses 
to  2nd  DP  ballot  and 
to  prepare  DIS  text. 

WG3 

Ad  Hoc 

To  rsscive  cint 

problems  with 
CGI/CGM  addenda 
drafting. 
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ISO/IEC  JTC1/SC24  RESOLUTIONS 


DRAFTS 


ISO/IEC  UTa/SC24  N18S 


RESOLUTION  17 — Working  Group  4  Ad  Hoc'Rapporteur/Editing  Meetings 

SC24  approves  the  following  schedule  of  meetings  for  its  Working  Group  4  for  the 
period  up  to  the  next  SC24  plenary  meeting: 


Oates 

Place 

Topic 

Category 

Purpose 

Sept. 

13-15 

Ft.  Collins 
USA 

Address  comments  on; 
DIS  PHIGS/FORTRAN 

Editing  Meeting 

Produce  IS 
PHIGS/FORTRAN 

1388 

Nov. 

11-12 

1983 

Amsterdam 

Netherlands 

Address  comments  on: 

DP  PHIGS/C  &  Pascal 
WO  GKS-3D/C  & 

WD  GKS/C 

Pre-meeting 

Prepare  draft 
responses  on 
PHlGS/C  &  Pascal 
GKS-3D/C  &  GKS/C 

Nov. 

14-15 

Amsterdam 

Netherlands 

Address  comments  on: 
DP  PHIGS/'C  8l  Pascal 

Editing  Meeting 

Recommend  DIS 
PHIGS/C  &  Pascal 

Nov. 

16-21 

1S88 

Amsterdam 

Netherlands 

comments  on: 

WD  GKS-3D/C.  AdA 

WD  GKS/C 

WG 

Recommend  dp 
GKS-3D/C  &  Ada 
GKS/C 

March 

1989 

Sheffield 

UK 

Address  comments  on: 
GKS-3D  FORTRAN 

Pre-meeting 

Prepare  draft 
responses  on 
GKS-3D/FCRTRAN 

March 

1989 

Sheffield 

UK 

Address  comments  on: 
GKS-3D  FORTRAN 

Editing  Meeting 

Produce  IS 

GKS-3D  FORTRAN 

March 

1389 

Sheffield 

UK 

Address  comments  on; 
GKS-3D  Pascal 

WG 

Recommend  DP 
GKS-30/Pascal 

[adjacent  to  WG1  and  AG] 

June 

S-3 

1989 

Melbourne 

USA 

Address  comments  on: 
PHIGS/Ada 

Pre-meeting 

P^eoare  draft 
resccnses  on 
FHIGS/Aca 

June  9 
1389 

Melbourne 

USA 

Address  comments  on: 
PHIGS/Ada 

Editing  Meeting 

Produce  IS 
PHIGS/Ada 
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June 

9-10 

1989 

Melbourne 

USA 

Address  comments  on: 
GKS/C,  GKS-3D/C  &  Ada 

Editing  Meeting 

Recommend  DIS 
GKS/C. 

GKS-3D/Ada&C 

June 

12-15 

1989 

Melbourne 

USA 

Address  comments  on: 
CGl/C  &  FORTRAN 

Ad  Hoc  WG 

Register  DP 
CGl/C&FORTRAN 

RESOLUTION  18 — SC24  Documents  for  Comment  and  3  Month  Letter  Ballot 

SC24  instructs  its  Secretariat  to  circulate  the  fcllcwing  documents  for  a  3  month  letter 
ballot: 


Document 

Title 

Comment  Processing 

SC24N171 

Procedures  for  preparing 

NWI  proposals 

Comments  resolved  at  Requirements 
meeting,  FRG,  March,  1983 

SC24N21 1  Rev 
SC24  N224 

NWI  proposal  for  Extensions 
to  PHIGS 

Comments  for  WG2  meeting 
Switzerland,  Jan  or  Feb  89. 

SC24N227 

NWI  propcsai  for  GKS 
Maintenance 

Comments  for  GKS  Maintenance  RG 
between  88-1 2  and  89-1 2 

SC24  N176Rev 

GKS  Maintenance  NWI 
Proposal 

Comments  for  GKS  Maintenance 

RG  between  88-12  and  39-12 

RESOLUTION  19 — Working  Group  5  Ad  Hoc'Rapporteur/Editlng  Meetings 
SC24  approves  the  following  schedule  of  meetings  for  its  Working  Group  5  for  the 
period  up  to  the  next  SC24  plenary  meeting: 


Dates  Place 

between  Dec  UK 

38  and  Fed  39  (Pink) 


Topic 
Registration 
Validation  and 
Testing 


[Along  with  GKS  maintenance  (WGl)] 


Category  Purpose 

WG  Review  comments. 
Produce  DP  Text 
liaison  GKS  maint 
Study  PICS 

aoplicapiiity 
Study  profile 

appiicaPiiity 


June  -  July  ??,  VTR 

1939  FRG 

(Kirsch) 


WG  Review  comments. 

Review  reg. 
proposals 


284 


ISO/IEC  JTC1/SC24  RESOLUTIONS 


DRAFT  3 


ISO/IEC  JTC1/SC24  Nia8 


Tha  WG5  meeting  between  December  88  and  Febnjary  89  will  be  held  in  parallel  with 
the  WG1  GKS  maintenance  rapporteur  group  meeting. 


RESOLUTION  20 — New  Structure  for  the  Next  Generation  of  Graphics 
Standards 

SC24  believes  that  the  currant  way  of  producing  standards  will  not  lead  to  coordinated, 
integrated,  timely  standards  with  international  scope  and  influence.  SC24  instructs  its 
Working  Group  1  to  investigate  the  feasibility  of  adopting  a  component/framewcrk 
structure,  as  described  in  SC24  N139  for  its  next  generation  of  graphics  standards  and 
notes  that  the  adoption  of  this  structure  may  require  a  new  development  process. 
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RESOLUTION  21 — Deadline  for  Finishing  Semantic  Standards 

SC24  resolves  that  the  CGI  project  not  be  subject  to  restructuring  under  the  new 
development  process,  unless  CGI  Parts  l-6  fail  to  progress  as  planned,  with  editing 
decisions  for  DIS  texts  taken  before  the  1989  SC24  plenary  meeting, 

RESOLUTION  22— OKS  Maintenance 

SC24  approves  the  following  procedure  and  schedule  for  GKS  Maintenance: 

1 )  A  draft  NWI  proposal  (SC24  N227)  will  be  circulated  for  National  Body  comment, 
with  comments  specifically  being  directed  at  the  extent  to  which  extensions  to  GKS 
functionality  shall  be  included  in  the  next  revision  of  GKS.  The  guidelines  contained  in 
Document  SC24  N176  should  be  observed  when  commenting  on  the  draft  NWI. 

2)  A  meeting  to  resolve  the  comments  and  to  prepare  a  final  NWI  and  base  document 
will  be  convened  by  Ken  Brodlie  and  held  in  the  UK  between  1983-12-01  and 
1989-02-28. 

3)  Subject  to  the  approval  of  the  SC24  Chair  and  the  WGl  Convenor,  the  NWI  will  be 
submitted  to  JTCl  for  ballotting  and  assignment  of  the  project  to  SC24/WG2. 

« 

4)  Simultaneously  with  step  3.  the  SC24  Secretariat  will  issue  a  conditional  ballot  to 
register  the  base  document  as  a  OP. 

5)  Subsequent  to  DP  registration,  the  SC24  Secretariat  will  issue  a  DP  ballot  on  the 
DP  text. 

6)  Upon  the  close  of  the  DP  ballot,  the  SC24  Secretariat  will  schedule  an  Editing 
Meeting  to  discuss  the  comments  received  on  the  DP  ballot  and  to  prepare  a 
disposition  of  comments  and  a  new  text. 
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RESOLUTION  23 — SC24  Documents  for  Study  and  Comment 

SC24  instructs  its  Secretariat  to  circulate  trie  foilcwing  documents  for  study  and 
comment.  Comments  are  to  be  submitted  as  indicated  below: 


Doc.  No. 

SC24  N177 

Title 

Working  Draft 

Reference  Model  for 

Computer  Grapriics 

Comments  Comments 

To  Whom  Due 

SC24  Seer.  I9aa*  10-20 

SC24/WG1 

Ref.  Model  Rapp. 

SC24  N173 

Trie  Use  of  Comocnent/ 
Framework  Description 
Tecriniques  in  trie 

Specification  of  Computer 
Grapriics  Standards 

SC24  Seer. 
WG1  Cenv. 

i9aa-io-30 

SC24  N179 

Sample  Forms  Used  to 

Acquire  and  Record 
Requirements 

SC24  Seer. 
SC24/WG1 
Requirements 
Rapporteur 

1993-10-30 

SC24  N175 

Terms  of  Reference 
for  Product  Data 

Geometry 

SC24  Seer. 
Product  Data 
Special 
Rapporteur 

1939-01-15 

SC24  Nias 

Working  Draft  Conformance 
Testing  of  Implementations 
of  Grapriics  Standards 

SC24  Seer. 
WG5  Corn/. 

VT  Rapp. 

1933-11-30 

SC24  N2C9 

CGI  criaracter  encoding  ID 

SC24  Seer. 

•  SC24/WG3 

1939-03-01 

SC24  N210 

CGI  binary  encoding  ID 

SC24  Seer. 
SC24/WG3 

1939-03-01 

SC24  N  1  ao 

GKS/C  WD  witri  trie  crianges 
agreed  in  Tucson. 

SC24  Seer. 
SC24/WG4 

1983-10-31 
for  Amsterdam 

SC24  N  iai 

GK3-3D/C  WD  witri  trie  cnangesSC24  Seer, 
agreed  in  Tucson.  SC24/WG4 

1933-10-31 
for  Amsterdam. 

SC24  N  139 

GKS-3D/AdaWD  witri  trie 
crianges  agreed  in  Tucson. 

SC24  Seer. 
SC24/WG4 

1933-10-31 
for  Amsterdam 
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SC24  N  190 

GKS-3D/Pascal  WO  with  the 

SC24  Seer. 

1988-12-31 

changes  agreed  in  Tucson. 

SC24/WG4 

for  Sheffield 

SC24  N  191 

CGI/C  WD  with  the  changes 

SC24  Seer. 

1989-04-15 

agreed  in  Tucson. 

SC24/WG4  ' 

for  Melbourne 

SC24  N  192 

CGI/FORTRAN  WD  with  the 

SC24  Seer. 

1989-04-15 

changes  agreed  in  Tucson. 

SC24AA/G4 

for  Melbourne 

SC24  N  1 93 

List  of  Approved  Abbreviations 

SC24  Seer. 

1989-04-01 

for  Bindings 

SC24/WG4 

SC24  N  194 

CGI  Language 

SC24  Seer. 

1989-04-01 

Bindings  issues  list 

SC24/WG4 

SC24  N  223 

Applicability  of  Static  Picture 

SC24  Seer. 

1989-04-01 

Capture  Flies  to  GKS-3D  and 
PHIGS 

SC24/WG3 

SC24  N229 

Reponsibilities  of  Liaison 
Officers 

SC24  Seer. 

1988-11-30 

SC24  N22a 

Explanation  of  Test 

SC24  Seer. 

1988-11-30 

Requirements 

SC24A/VG5 

RESOLUTION 

24 — Registration  Letter  Ballot 

SC24  instructs  its  Secretariat  to  drculate  a  90  day  letter  ballet  on 
N22S  regardless  of  the  status  of  ISO/TR  9973  (SC24  N1 32) . 

document  SC24 

Comments 

Comments 

Doc.  No. 

Title 

To  Whom 

Dus 

SC24  N134 

Registration  Proposals 

SC24  Seer. 
WG5  Cenv. 

Reg.  Rapp. 

1988-11-30 
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RESOLUTION  25— SC24  Meeting  Plan  for  1989  Plenary 

SC24  approves  the  following  meeting  schedule  for  its  WGs  in  conjunction  with  SC24 
Plenary  in  Brazil  in  1989: 


m  a  plenary 


.  :  'i  I  I  I  I  I 

M  T  W  r  ?  3  S:M!T  WiT'; 


SC24  Plenary _ (2  davs) 

Advisory  Group  L24iiours) 
WGl:  Plenary  iUi 


XX  ix  n;'  X! 

V  x:x  aO  i 


X'  X 
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RESOLUTION  26 — Liaison  Statements 

SC24  approves  the  following  liaison  statements  and  instructs  its  secretariat  to  forward 
them  to  the  indicated  liaison  organizations: 


Ooc.  No. 

SC24  N208 

Title 

Liaison  Statement  to  SCI  8  Regarding  SPDL 

To  Whom 
SCia 

SC24  N198 

Response  to  TC10  and  UK  Comments  on 
Proposal  for  Registration  of  Graphical  Items 
{ISO/IEC  JTC1/SC24  N132) 

TC10 

SC24  N216 

Response  to  SCia  N1383  (SC24  N1ia) 

SCia 

SC24  N  217 

Comments  on  SC22  N466, 

Guidelines  for  Language  Bindings. 

SC22 

SC24  N212 

Liaison  Statement  to  SC22 

SC22 

RESOLUTION  27 — Documents  for  OP  Ballot 

In  recognition  of  the  substantial  progress  made  with  the  CGI  at  the  Tucson  meeting 
SC24  instructs  its  Secretariat  to  circulate  the  text  resulting  from  the  September  1988 
CGI  Drafting  meeting  for  2nd  DP  ballot  The  Document  Editor  is  instructed  to  make  the 
text  resulting  from  the  September  1988  Drafting  meeting  available  to  the  SC24 
Secretariat  by  IS  November  1988. 


RESOLUTION  23 — Structure  of  Work  on  20  Metafiles 

Whereas  it  was  decided  at  the  SC21/WG2  meeting  at  Egham  in  1986  that  a  QKSM 
should  be  produced  in  a  timely  fashion  by  an  addendum  to  CGM,  and 

whereas  the  Metafile  Rapporteur  Group  of  WG3  has  substantially  completed  the 
technical  work  including  the  extensions  for  both  a  static  picture  capture  metafile  and  a 
GKS  metafile  to  replace  annex  E  of  GKS  IS  7942,  and 

whereas  the  Metafile  Rapporteur  Group  believes  for  the  reasons  detailed  in  SC24 
N154,  SC24  N156  and  SC24/WG3  N32.  that  there  are  technical  problems  with 
continuing  to  progress  the  GKS  Metafile  portion  of  Addendum  1  as  an  addendum  to 
CGM, 


therefore  SC24  directs  WG3  to  convert  the  GKS  Metafile  portion  of  Addendum  1  from 
an  addendum  to  CGM  to  an  addendum  containing  a  non-normative  annex  to  GKS  IS 
7942  and  if  possible  progressed  in  the  same  timescale  as  CGM  addendum  1.  Further, 
this  should  become  a  normative  annex  to  GKS  during  the  maintenance  process  of 
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GKS. 


RESOLUTION  29— Structure  of  Work  on  3D  metafiles 

Whereas  it  was  decided  at  the  SC21/WG2  meeting  at  Egham  in  1986  that  a  GKS-3D 
metafile  should  be  produced  in  a  timely  fashion  by  an  addendum  to  CGM,  and 

whereas  the  Metafile  Rapporteur  Group  of  WG3  has  substantially  completed  the 
technical  work  including  the  extensions  for  both  a  3D  static  picture  capture  metafile 
and  a  GKS-3D  metafile  to  replace  annex  E  of  GKS-3D  ISO/IEC  DIS  8805,  and 

whereas  the  Metafile  Rapoorteur  Group  believes  for  the  reasons  detailed  in  SC24 
N154,  SC24  N1S6  and  SC24/WG3  N32,  that  there  are  technical  problems  with 
continuing  to  progress  the  GKS  3*0  Metafile  portion  of  Addendum  2  as  an  addendum 
to  CGM. 

Therefore  SC24  directs  WG3  to  convert  the  GKS-3D  Metafile  portion  of  Addendum  2 
from  an  addendum  to  CGM  to  an  addendum  containing  a  non-normative  annex  to 
GKS*30,  ISO/IEC  DIS  8805  and  progressed  in  the  same  timescale  as  CGM  addendum 
2. 


RESOLUTION  32— Withdrawal  of  OP  Registration  for  GKS/C 

SC24  withdraws  the  aporoval  for  DP  registration  for  GKS/C  (SC21  N1413)  because 
the  process  of  converging  GKS/C  with  other  GKS-3D  and  PHIGS  bindings  has 
produced  an  almost  totally  new  document  which  is  being  recommended  for  Working 
Craft  circulation. 


RESOLUTION  34— SC24  Delegation  of  Authority 

SC24  approves  the  delegation  of  authority  to  SC24/WG4  to  foPA/ard  documents  for 
registrahon  as  draft  proposals  and  instructs  its  Secretariat  to  register  the  following 
documents  for  DP  letter  ballot: 


Document  Title  Meeting  to  register 


GK3-3D/Ada 

GKS-3D/C 

GKS/C 


November  1988  meeting  in  Amsterdam 
November  1988  meeting  in  Amsterdam 
November  1988  meeting  in  Amsterdam 


GKS-3D/Pascal  March  1989  meeting  in  Sheffield,  UK 
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CGiyC  June  1989  meeting  in  Melbourne,  USA 

CGI/FORTRAN  June  1989  meeting  in  Melbourne,  USA 

RESOLUTION  35— Prompt  Circulation  of  Comments  to  Document  Editors 

SC24  instructs  its  secretariat  to  distribute  copies  of  National  Body  comments  to  the  editor 
of  the  impacted  document  as  the  comments  are  received. 


RESOLUTION  36 — Language  Bindings  for  Registered  Items 

SC24  recognizes  the  value  of  correct  language  bindings  for  registered  items. 

SC24  requests  that  National  Bodies  shall  not  forward  incomplete  proposals,  including 
missing  language  bindings,  to  the  Registration  Authority  because  SC24/WG4  is  not 
required  to  originate  language  bindings  for  proposals  when  these  bindings  are  missing. 


RESOLUTION  37— SC24  Documents  for  DIS  Registration 

SC2.4  instructs  its  Secretariat  to  forward  the  following  document  to  ISO  Central 
Secretariat  for  registration  as  a  Draft  International  Standard: 

The  PHIGS  binding  to  Ada  (ISO  9593-3),  with  the  changes  agreed  in  Tokyo  and 
discussion  and  resolution,  in  Tucson,  of  the  issue  contained  in  SC24/WG4/N01 1 . 
DIS  text  will  be  provided  to  SC24  Secretariat  in  September  1988,  following 
validation  of  the  resolution  of  the  last  issue. 


RESOLUTION  38 — Simultaneous  Development  of  Semantic  Standards  and 
Language  Bindings 

SC24  adepts  the  following  policy: 

That  all  functional  specifications  which  reach  the  stage  of  DIS  or  IS  should  be 
accompanied  by  at  least  one  language  binding  or  encoding  for  that  functional 
specification.  Specifically,  if  the  functional  specification  is  at  the  stags  of  DIS,  at  least 
one  'anguage  binding  cr  encoding  should  be  at  the  stage  of  CP.  and  if  the  funcicnal 
specification  is  to  become  an  IS,  at  least  one  language  binding  or  encoding  should  be 
at  the  stage  of  DIS. 
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RESOLUTION  39— Progression  of  PHIGS  C  and  PHIGS  Extended  Pascal 


SC24  instructs  its  Secretariat  to  check  that  the  C  language  standard  is  at  DIS  stage 
before  registering  the  PHIGS  C  Language  Binding  as  a  DIS.  and  that  the  Extended 
Pascal  language  standard  is  at  DIS  stage  before  registering  the  PHIGS  Extended  Pascal 
Language  Binding  as  a  DIS. 


RESOLUTION  40 — Conformance  Testing  Standard  Progression 

SC24  approves  the  progression  of  project  JTCl.24.7  as  a  single  part  standard.  The 
standard  will  contain  general  concepts  and  guidelines  for  conformance  testing  of  the 
complete  range  of  graphics  standards.  Specific  details  for  each  standard  will  be 
produced  in  a  Test  Requirements  document  for  each  standard. 


RESOLUTION  42 — Conformance  Clauses 

SC24  approves  the  following  procedures  for  developing  and  reviewing  the  conformance 
sections  of  Semantic  Standards  developed  within  SC24; 

1.  The  current  draft  of  the  Conformance  Testing  Standard  (project  JTCl.24.7)  should 
be  consulted. 

2.  The  SC24/WG5  Convenor  and  the  Validation  and  Testing  Rapporteur  should  be 
notified  of  the  place  and  time  of  discussions  relating  to  the  Standard  conformance 
sections  and  WG5  experts  should  be  invited  to  participate  in  these  discussions. 

3.  The  text  for  the  conformance  sections  shall  be  developed  jointly  by  the  WG5 
Validation  and  Testing  Rapporteur  Group  and  the  Standard  Group. 


RESOLUTION  43— PICS  Proforma 

SC24  instructs  its  Working  Group  5  to  investigate  the  use  of  PICS  (Protocol 
Implementation  Contormanca  Statement)  proformas  to  assist  in  the  development  of 
conformance  requirements  and  the  application  of  conformance  test  suites  for  grapnics 
standards.  WG5  is  instruaed  to  produce  a  report  by  15  March  1S89  for  circulation  to 
3C24  National  Bodies  for  comment  by  15  July  1989.  The  SC24  Chair  will  wnte  to  the 
SC21  Chair  to  request  SC21  panicipation  in  this  work. 

RESOLUTION  44 — Application  Profiles 

SC24  instructs  its  Working  Group  5  to  investigate  the  applicability  of  Application  and 
Constituency  Profiles  and  their  relationship  to  graphics  standards  and  registration.  In 
particular,  WG5  should  examine  whether  the  profiles  can  assist  in  the  definition  cf 
conformance  requirements  and  consider  if  SC24  should  be  involved  in  the 
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standardisation  or  registration  of  profiles.  The  SC24  Chair  will  write  to  the  SC2l  Chair  to 
request  SC21  participation  in  this  work. 


RESOLUTION  46— Appreciation  to  GKS  Binding  editors 

SC24  unanimously  expresses  its  appreciation  to  D.  Larson,  editor  of  GKS  Pascal 
(ISO/IEC  8651-2)  and  J.  McConnell,  editor  GKS  FORTRAN  (ISO/IEC  8651-1)  on 
publication  of  the  standard  and  completion  of  their  work. 

RESOLUTION  47— SC24  Five  Year  Meeting  Plan 

SC24  approves  the  following  five  year  plan  for  its  plenary  meetings  and  notes  that  SC24 
meetings  are  held  at  least  each  1 8  months. 

Dates  Place 

1 5  Oct.  - 1 5  Nov  1 989  Iguassu  Falls,  Brazil 

April  1991  U.K. 

October  1 992  Germany.  F.R. 

April  1994  Franca 

RESOLUTION  48— EEC  Standardisation  Activities  Within  JTC1/SC24 
Scope  of  Work  [Denmark,  FRO] 

Whereas 

1 )  SC24  is  aware  that  the  EEC  Commission  is  developing  standard  activities  which 
are  thoroughly  related  to  the  scope  of  work  of  SC24  such  as: 

-  GPOS  (PPSC-IT  N252),  (Generalized  Portable  Operating  System); 

2)  the  European  Standards  (EN)  have  a  higher  priority  for  EEC  and  EFTA  countries, 

SC24  offers  to  cooperate  and  assist  in  developing  the  on-going  EEC  standard  activites, 
with  regard  to  the  SC24  area  of  work  (Computer  Graphics). 
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ISO/lEC  UTC1;SC24  RESOLUTIONS 


DRAFT  3 


ISO/IEC  JTC'I/SC24  N188 


RESOLUTION  50 — S024  Appreciation  for  Meeting 

SC24  unanimously  expresses  its  appreciation  to  the  meeting  organizers  and 
contributors: 


Organization 
Secretarial  Support 

Rnancial  Support 


Computer  Support 


Peter  R.  Bono  Associates,  Inc. 

Susan  Bonde,  Diane  Bono,  Elaine  Bono,  Brenda  Carson, 
Gillian  Hail 

National  Computer  Graphics  Association 
Advanced  Technology  Center 
Apoilo  Computer 
Digital  Ecuicmeni  Corporation 
Hewiett-Packard  Company 
International  Business  Machines 
Lcckheed/CalComp  Corporation 
National  Semiconductor  Corporation 
Pansophic  Systems,  Inc. 

Precision  Visuals,  Inc. 

Tektronix,  Inc. 

Unisys  Corporation 
Chin  Assocates 
Geri  Cuthbert 
GSC  Associates  Inc. 

Sun  Microsystems,  Inc. 


SC24  unanimously  expresses  appreciation  to  its  Chair,  Dr.  Jurgen  SchSnhut,  the 
Secretariat,  and  the  Drafting  Committee  {G.S.  Carson,  C.  Cartledge,  I.  Korn,  and  J. 
Rix)  for  their  work  in  support  of  the  meeting. 


RESOLUTION  51 — Appreciation  to  Janet  Chin 

SC24  unanimously  expresses  their  appreciation  to  Janet  Chin  for  years  of  unstinting 
effort  as  leader  of  the  US  delegation. 


RESOLUTION  52 — Language  Binding  Issues  Librarians 

SC24  notes  that  WG4  has  established  the  position  of  issues  librarian  for  eacn 
'anguage  binding.  The  duties  cf  issues  ibranans  are  to  record  issues,  including  their 
arguments  and  resolutions,  and  maintain  and  circulate  the  library.  SC24  directs  its 
Working  Groups  to  identify  to  the  WG4  convenor  those  individuals  from  their 
membership  who  can  participate  in  the  activities  of  WG4  in  this  role,  on  a  part  time 
basis. 
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ISO/IEC  JTCi;SC24  RESOLUTIONS 


DRAFTS 


ISO/IEC  JTC1/SCS4  N18S 


RESOLUTION  53 — SC24  Documents  for  OP/POAO  registration 


SC24  instructs  its  Secretariat  to  circulate  the  following  documents  for  parallel  PDAD 
registration  ballot  and  conditional  PDAD  ballot; 


Document  no. 

Title 

Condition 

SC24  N219 

CGM  Addendum  2,  part  1 

As  amended  by  decisions  taken  at 
Tucson 

SC24  N22C 

CGiVl  Addendum  2.  part  2 

As  defined  by  decisions  taken  at 
Tucson 

SC24  N221 

CGM  Addendum  2,  part  3 

As  defined  by  decisions  taken  at 
Tucson 

SC24  N222 

CGM  Addendum  2,  part  4 

As  defined  by  decisions  taken  at 
Tucson 

RESOLUTION  54— SC24  Documents  for  DIS/OAD  registration 

SC24  instructs  its  Secretariat  to  forward  the  following  documents  to  the  JTCl 
Secretariat  for  DAD  ballot: 


Document  no. 

Title 

Condition 

SC24  N230 

CGM  Addendum  1 , 

part  1 

As  amended  by  decisions  taken  at 
Tucson 

SC24  N231 

CGM  Addendum  1 , 

parts 

As  amended  by  decisions  taken  at 
Tucson 

SC24  N232 

CGM  Addendum  1 , 

part  3 

As  amended  by  decisions  taken  at 
Tucson 

SC24  N233 

CGM  Addendum  1 , 

part  4 

As  amended  by  decisions  taken  at 
Tucson 

SC24  N234 

GKS  Addendum  1 

To  be  derived  from  all  parts  of  CGM 
addendum  1 ,  following  the  decisions 

taken  at  Tucson 


RESOLUTION  55 — SC24  Document  for  Registration  Sponsorship 

SC24  directs  its  Secretariat  to  circulate  the  registration  proposals  in  Document  SC24 
N225  fcr  a  3  month  letter  ballot  to  approve  SC24  sponsorship  of  them  for  registration 
as  graphical  items. 
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RESOLUTION  56— E:«tended  Scope  of  the  Register  of  Graphical  items 


SC24  directs  the  WGo  Registration  Racpcrteur  Group  to 
registration  procedures  can  be  extended  to  cover  the 
requiured  for  registration  by  SC24  standards. 


consider  ways  in  which  the 
adciticnal  graphical  iten^s 


NIST-1 14A 
(REV.  3-89) 

U.S.  DEPARTMENT  OF  COMMERCE 
NATIONAL  INSTITUTE  OF  STANDARDS  AND  TECHNOLOGY 

1.  PUBUCATION  OR  REPORT  NUMBER 

NISTIR  4316 

BIBLIOGRAPHIC  DATA  SHEET 

Z  PERFORMING  ORGANIZATION  REPORT  NUMBER 

3.  PUBUCATION  DATE  ^  y  ^  ^  t 

MARCH  1991 

4.  TITLE  AND  SUBTITLf 

A  Collection  of  Technical  Studies  Completed  for  the  Computer-A 
Support  (CALS)  Program  Fiscal  Year  1988  Volume  2  of  3,  Graphic 

ided  Acquisition  and  Logistic 
s,  CGM  MIL  SPEC 

5.  AUTHOR(S) 

Roy  S.  Morgan,  Editor 

6.  PERFORMING  ORGANIZATION  (IF  JOINT  OR  OTHER  THAN  NIST,  SEE  INSTRUCTIONS) 

U.S.  DEPARTMENT  OF  COMMERCE 

NATIONAL  INSTITUTE  OF  STANDARDS  AND  TECHNOLOGY 

GAITHERSBURG,  MO  20899 

7.  CONTRACT/GRANT  NUMBER 
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development  of  technology  and  standards  in  support  of  CALS.  These  reports  are  divided  into 
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3,  Graphics,  CGM  Registration. 
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CALS  CGM  application  profile, 
for  Extended  CGM  is  presented. 


in  the  Computer  Graphics  Metafile  standard  is  aescribed, 
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